Re: Add CREATE support to event triggers - Mailing list pgsql-hackers

Can we please stop arguing over a problem I don't have?  I started with
CREATE SCHEMA because it is one of the easy cases, not because it was
the most difficult case: we only need to deparse the bits of it that
don't involve the objects within, because those are reported by the
event trigger as separate commands.  Each object gets its own creation
command, which works pretty nicely.  Of course, the deparsed version of
the command will not look very much like what was submitted by the user,
but that doesn't matter -- what does matter is that the objects created
by running the commands reported in the event trigger will be (or should
be) the same as those created by the original command.

I was showing CREATE SCHEMA as a way to discuss the fine details: how to
report identifiers that might need quoting, what to do with optional
clauses (AUTHORIZATION), etc.  I am past that now.

On the subject of testing the triggers, Robert Haas wrote:

> Here's one idea: create a contrib module that (somehow, via APIs to be
> invented) runs every DDL command that gets executed through the
> deparsing code, and then parses the result and executes *that* instead
> of the original command.  Then, add a build target that runs the
> regression test suite in that mode, and get the buildfarm configured
> to run that build target regularly on at least some machines.  That
> way, adding syntax to the regular regression test suite also serves to
> test that the deparsing logic for that syntax is working.  If we do
> this, there's still some maintenance burden associated with having DDL
> deparsing code, but at least our chances of noticing when we've failed
> to maintain it should be pretty good.

I gave this some more thought and hit a snag.  The problem here is that
by the time the event trigger runs, the original object has already been
created.  At that point, we can't simply replace the created objects
with objects that would hypothetically be created by a command trigger.

A couple of very hand-wavy ideas:

1. in the event trigger, DROP the original object and CREATE it as
reported by the creation_commands SRF.

2. Have ddl_command_start open a savepoint, and then roll it back in
ddl_command_end, then create the object again.  Not sure this is doable
because of the whole SPI nesting issue .. maybe with C-language event
trigger functions?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services