Господа, как правильно дебажить триггеры ?
допустим добавил в функцию RAISE NOTICE'b_id = % ...
а где вывод смотреть ?

в логе postres-а ЕМНИП

а где он ?
, ни разу не пользовался

пользуюсь navicat и больше ничего

как запускаете базу?

то есть? вы видимо понимаете под амазоном какой то его сервис, а у него уже под капотом находится какая либо БД

через navicat пишу, но в Message ведь нет вывода из триггера.
он фоново срабатывает, узнаю только если будет какая-то ошибка

что-то не так делаю
поставил в postgresql.conf
#log_statement = 'all'  
и сделал
pg_reload_conf()
в логах по пути c:\Program Files\PostgreSQL\13\data\log\
RAISE NOTICE' не появляются

коммент перед параметром уберите )

ага, теперь вываливается, но не сообщения RAISE NOTICE...
блин как их увидеть в триггерах ?

спасибо  ... появилось
неудобно конечно, в navicat бы сразу смотреть, но лучше так, чем вообще никак

postgres вероятнее всего умеет писать в журнал виндовый, а для него уже скорее всего есть удообные просмотрщики

да мне только триггер отладить, а не вслепую тыкать. Рядом, в sublime смотрю лог

Стало интересно. Сильно вряд ли наша задача прямо такая вся уникальная, если отбросить особенности реализации, в общем виде клиент-серверного исполнения коннекшен имеет все шансы быть один на X юзеров, при этом юзеры имеют все шансы быть в разных часовых поясах. Те же задачи поиска и бронирования записей в календарях (авиабилеты, как очень грубый пример). То есть, в лучшем случае все можно свести к обработке массовых запросов с timestanptz between boundary_ts_bottom and bounday_ts_top плюс поправки на приведение к таймзонам. И кажется, что в этом месте реляционные СУБД "из коробки" в принципе - решение не самое удачное по производительности. Как люди с этим живут, любопытно?

Отличная мысль. И базовые операторы переопределить (=, <, >, BETWEEN), на клиенте или на сервере, чтобы что-то такое подставляли.

В основном — выкручиваем ся, чтобы на сервер приходили ужэ разобранные функцыи, только прямые аналоги field < const, field > const.

Но тут мало у кого есть полноцэнный язык на клиенте, который надо было бы парзить, чаще какой календарик простенький или два поля ввода дат.

То есть с клиента приходит уже, в данном случае, готовый timestamptz для простого сравнения, а дальше обычный индекс помогает? Да, так можно жить :)

> если отбросить особенности реализации

А давайте не отбрасывать. Как говорится, удаление гланд — не "прямо такая вся уникальная задача", но у тех, кто их удаляет автогеном, почему-то появляются какие-то проблемы. Понимаете, к чему я веду? ;)

> коннекшен имеет все шансы быть один на X юзеров

Да, так бывает.
Только, тем не менее, почти всегда есть чёткое разделение в отношении того, какой именно user с ним сейчас работает (а иначе как-то много с чем нормально работать не получается — хоть с настоящими правами доступа, например). Т.е. когда соединение начинает "представлять" пользователя X, в норме и происходит какая-то реинициализация — и вот её частью и является SET timezone = .

> решение не самое удачное по производительности.

Не вижу, как это "вывод" следует из предыдущего?!

> Как люди с этим живут, любопытно?

Люди не удаляют гланды автогеном, и живут нормально, представляете? ;)

Зачем?! Зачем Вы это делаете? Я вон пример показывал, как это делается адекватно, в чём с ним проблема-то?!

См. ответ выше.