Tory M Blue wrote
> Hi
> I am going to add a new column to a table for modify_date that needs to be
> updated every time the table is updated. Is it better to just update
> application code to set the modify_date to current_time, or create a
> Before-Update trigger on the table that will update the modify_date column
> to current_timestamp when the table is updated? I also have slony in
> place,
> so the trigger will need to be on master and slave. Slony will take care
> of
> suppressing it on the slave and enabling in the event of a switchover, but
> it is additional overhead and validation to make sure nothing failed on
> switchover.
>
> So considering that we have slony, is it better to use application code to
> update the modify_date or use a trigger? Is a trigger essentially 2
> updates
> to the table? Are there any other risks in using the trigger?
>
> Thanks
>
> Tory Blue
Not sure about the Slony trade-off but a before trigger will intercept
before any physical writes and so appears to be a single action. I would
generally use a trigger so that you know the updared value is recorded (and
can readily add logic for the no-changes situation - if desired). Not all
table activity has to be initiated by "the application" and since forgetting
to do so is not going to result in any kind of error the probability of the
field becoming useless is non-zero.
It will be slower than doing it native but whether or not that is
significant enough to discard the advantages of triggers is something only
you can decide - ideally after testing.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Best-practice-question-tp5801010p5801011.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
