From: | Erik Wienhold <ewie(at)ewie(dot)name> |
---|---|
To: | Lian Jiang <jiangok2006(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: event trigger should provide more details |
Date: | 2023-05-30 23:03:24 |
Message-ID: | 694730690.528476.1685487804385@office.mailbox.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On 31/05/2023 00:28 CEST Lian Jiang <jiangok2006(at)gmail(dot)com> wrote:
>
> The info useful for me is command_tag, object_type, object_identity.
> classid, objid is not useful since object_identity is more explicit.
> objsubid is not useful because I don't need comment
> (https://www.postgresql.org/message-id/Pine.LNX.4.33.0212091822050.15095-100000@leary.csoft.net)
> information for schema change.
You need objsubid to identify the column in pg_attribute to get its type, not
just to get the comment from pg_description as the linked thread says.
> Besides table name, I still need:
> * which columns are added and their types.
> * which columns have type change, the old and new types.
> * which columns are dropped.
>
> Will command field provide this info? I don't have an example and decoding it
> needs C code (https://www.postgresql.org/message-id/20190712222343.GA26924%40alvherre.pgsql)
> If I cannot get such info from pg_event_trigger_ddl_commands, I may need to
> maintain schema snapshots myself and diff the old and new snapshots upon an
> alter table/view event. Which way should I go? Thanks a lot.
Right off the bat, I would combine it with a ddl_command_start event trigger to
record the necessary info (current columns and their types) in a temp table.
Query this table in the ddl_command_end event trigger to figure out which
columns have changes. This can be done entirely in plpgsql without using the
command column.
--
Erik
From | Date | Subject | |
---|---|---|---|
Next Message | Randy Needham | 2023-05-30 23:17:00 | Re: Having issue with SSL. |
Previous Message | Lian Jiang | 2023-05-30 22:28:22 | Re: event trigger should provide more details |