From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Before image of selective columns. |
Date: | 2025-01-10 14:43:46 |
Message-ID: | CANzqJaCUTtUH44C6FJDXJ2ZwFFWjMCQz-pV_QmnVVaUJUhuAhw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Fri, Jan 10, 2025 at 8:41 AM Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
wrote:
> > On Jan 10, 2025, at 2:55 AM, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
> wrote:
> >
> > That looks like a job for a trigger; perhaps a statement level trigger
> > with a transition table.
>
> Indeed.
>
> I just want to add from experience: put the row values into a JSON column
> in the audit table. Otherwise, what do you do when the table definition
> changes? It's not just that you would have to keep the audit table schema
> in sync, it's possible to have a change which is not compatible with the
> old definition, such that you now really can't have one table that covers
> both old and new exactly, and then have to resort to renaming columns or
> some such...
>
For years, we've used triggers to populate such tables, but never had
incompatibility problems. Mainly because we add new columns and upsize
existing columns to compatible types.
Everyone's situation is different, though.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
From | Date | Subject | |
---|---|---|---|
Next Message | kasem adel | 2025-01-12 20:42:07 | Archiving solutions |
Previous Message | Scott Ribe | 2025-01-10 13:40:59 | Re: Before image of selective columns. |