On Tue, 2025-11-04 at 12:48 +, PALAYRET Jacques wrote:
> In a trigger body, is there a simple way to know if a column value has been
> explicitely modified ?
> Explicitely modified ; in others words, typically indicated in the SET clause
> of the UPDATE.
> A simple way ; I mean without analys
Again, speaking for myself only and not officially for Quest.
" Uh, people will say that if the solution is not 100% secure in its coverage,
it is much less useful and therefore not worth it."
I would assert that NO system is "100% secure" given enough money and
resources. I think the more im
PALAYRET Jacques writes:
> In a trigger body, is there a simple way to know if a column value has been
> explicitely modified ?
> Explicitely modified ; in others words, typically indicated in the SET clause
> of the UPDATE.
I believe that an ON UPDATE trigger coded in C can access a bitmapse
On Tue, Nov 4, 2025 at 1:49 PM PALAYRET Jacques
wrote:
> In a trigger body, is there a simple way to know if a column value has been
> explicitely modified ?
Using pg_trigger_depth(), you can know whether the trigger is called
from "outer SQL" directly,
or from SQL done within another trigger (b
Hello,
In a trigger body, is there a simple way to know if a column value has been
explicitely modified ?
Explicitely modified ; in others words, typically indicated in the SET clause
of the UPDATE.
A simple way ; I mean without analysing the SQL statement which can be very
difficult accordi
On 2025-Nov-04, Laurenz Albe wrote:
> 9.6, which introduced parallel query, only supported it for sequential
> scans, which was much less useful than what we have today. I for one
> wouldn't consider an implementation of TDE with some features missing
> "not worth it".
We call this incremental d
