Re: Trigger (or something similar) on table rename? - Mailing list pgsql-general

From Ken Tanzer
Subject Re: Trigger (or something similar) on table rename?
Date
Msg-id CAD3a31VSthX3bW1a9urii1tra1UCd2+9J=zCUW+jj0C9SLVOsQ@mail.gmail.com
Whole thread Raw
In response to Re: Trigger (or something similar) on table rename?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Trigger (or something similar) on table rename?
List pgsql-general


On Thu, Feb 15, 2018 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ken Tanzer <ken.tanzer@gmail.com> writes:
> Something like a trigger on the table rename would be ideal for my
> purposes.  Anything like that possible?  Thanks!

Recent PG versions have "event triggers" which would serve the purpose.
However, the infrastructure for them isn't very fully built out yet.
I'm not sure if you could identify a table rename without resorting to
writing some C code.

                        regards, tom lane


Hi, and thanks for the responses.  As a follow-up, I see you can use pg_event_trigger_ddl_commands() to get some info.  One of the things it returns is a pg_ddl_command ("A complete representation of the command, in internal format. This cannot be output directly, but it can be passed to other functions to obtain different pieces of information about the command.")

Presumably the complete command would let you figure out it's a rename, and the old and new tables.  But I found this message (https://postgrespro.com/list/thread-id/1561932) stating that a pg_ddl_command could only be processed in C, not in a procedural language.  I'm wondering if that just hasn't been implemented yet and is likely to change at some point, or if there is some kind of inherent limitation involved.

Also, is there a link somewhere that does document the pg_ddl_command, in case I did end up trying to work this in C?

Cheers,
Ken

--
AGENCY Software  
A Free Software data system
By and for non-profits
(253) 245-3801

learn more about AGENCY or
follow the discussion.

pgsql-general by date:

Previous
From: Olegs Jeremejevs
Date:
Subject: Rationale for PUBLIC having CREATE and USAGE privileges on the schema"public" by default
Next
From: Ken Tanzer
Date:
Subject: Any hope for more specific error message for "value too long..."?