наверное в чистом виде такого поведения, чтобы при вставке/апдейте с SET моеполе = блаблабла вставлялось всегда и именно блаблабла а без - всегда в т.ч. апдейтилось на default добиться нельзя (можно с точностью до того, что когда и если , однако разрулив на 2 триггера (или ветки)-дабы "олд" не прорезался при инсерте) - что чревато тем, что при случайном совпадении нью=олд для большого апдейта с явным сетом эти записи таки отапдейтятся на дефолт вместо нью.

однако можно чтобы _всегда_ апдейтилось на дефолт, а для ручной правки с помощью скл-стейтмента сделать в триггере TG_ARGV[], для чего вести скажем служебную табличку с одной записью==полем==переменной. И такой апдейт делать в транзакции (или в спец хп)


как юзать TG_ARGV[], читать здесь Триггер с параметрами

ну так сам бог велел ваш "синхронизатор" запущать в отдельной транзакции/сессии со сменой всего одной "переменной сессии" (под переменной сессии может подразумеваться любой временный объект, существующий либо только внутри транзакции, либо внутри сессии).
и тогда вам надо только поменять триггерную ф-ю на параметрическую, и процедуру старта "синхронизатора" (если тот держит одну сессию) - устанавливать там ту самую "переменную сессии".

Но если "синхронизатор" ваш коннектится внутри сеанса своей работы много и безсистемно (т.е. создает массу разных сеансов на сервере бд), - придется поменять все вызовы апдейта из синхронизатора (перед каждым апдейтом устанавливать "переменную сессии"), или все места установления начала сессии-соединения. Т.е. возможно - несколько мест. а не одно.

ShagratДа дискуссия затянулась.

А можно реальный пример реализации. Если можно то рабочий.чего ж реальней то

ShagratА можно реальный пример реализации. Если можно то рабочий.зы
лудше писадь таг:
автор"а можно примерный пример реальной реализации"

ShagratМожет есть способ увидеть данные переданные в запросе.
И в зависимости от них брать дату из запроса, или ставить свою
добраться из триггерной фунции можно сюда
авторWhen a PL/pgSQL function is called as a trigger, several special variables are created automatically in the top-level block. They are:

NEW
Data type RECORD; variable holding the new database row for INSERT/UPDATE operations in row-level triggers. This variable is NULL in statement-level triggers.

OLD
Data type RECORD; variable holding the old database row for UPDATE/DELETE operations in row-level triggers. This variable is NULL in statement-level triggers.

TG_NAME
Data type name; variable that contains the name of the trigger actually fired.

TG_WHEN
Data type text; a string of either BEFORE or AFTER depending on the trigger's definition.

TG_LEVEL
Data type text; a string of either ROW or STATEMENT depending on the trigger's definition.

TG_OP
Data type text; a string of INSERT, UPDATE, or DELETE telling for which operation the trigger was fired.

TG_RELID
Data type oid; the object ID of the table that caused the trigger invocation.

TG_RELNAME
Data type name; the name of the table that caused the trigger invocation.

TG_NARGS
Data type integer; the number of arguments given to the trigger procedure in the CREATE TRIGGER statement.

TG_ARGV[]
Data type array of text; the arguments from the CREATE TRIGGER statement. The index counts from 0. Invalid indices (less than 0 or greater than or equal to tg_nargs) result in a null value. как видим - никаких TG_SETS[] и т.п аналогов там не наблюдается. ДУмаю - приведенный набор рулящих пимпочек триггера исчерпывающий.

Т.ч. либо вместо инсерт/апдейта пишите свои хп с полным перечнем и модифачьте поведение базы как требуется, либо придумывайте иной велосипед. (скажем -перехватывать текст стейтмента до его выполнения сервером и само-парсить в свой набор переменных сессии/транзакции. или, на худой, реализуйте вызов всех стейтментов из ваших прилад через экзекютирующую их ХП. но с предпарсингом (перед вызовом EXECUTE) строки передаваемого стейтмента в набор переменных.

Иде Я: Кстати, попробуйте написать DO INSTEAD RULE подменяющую вставку/апдейт в таблицу с дефолтами, на вставку/апдейт в таблицу _без_ дефолтов, а там проверьте, что придет вместо NEW - набор данных из апдейтируемой записи подменённой , или подменяющей таблицы. Вряд ли, предвкушаю, найдется дырка, но "а вдруг"?)

а так - ну попробуйте пользоваться ф-ей с одной дыркой в логике:

надо поменять либо на
либо на

но это, как уже предупреждалось, не спасет ситуацию при совпадении (т.е. ,в частности, при повторном запуске апдейта с прописанным SET mofify=xxxxx)