Re: Add CREATE support to event triggers

Here's a refreshed version of this patch. I have split it up in a
largish number of pieces, which hopefully makes it easier to understand
what is going on. First there are a number of trivial fixups which
mostly shouldn't require much of an explanation, or add functionality to
ruleutils that later patches need. I also split builtins.h to create a
new ruleutils.h header, in which there are several prototypes for
functions in ruleutils.c. (The reason for this is that a later patch
adds a bunch more prototypes which require other headers to be #included
by ruleutils.h, and it didn't seem a good idea to include those in
builtins.h. This doesn't affect much -- only 7 .c files had to #include
the new file.)

The first really interesting patch is 0014, which introduces the concept
of a "command queue" in event triggers, where DDL commands are stored as
parse nodes plus supporting data. At ddl_command_end, the user code can
call the new pg_event_trigger_get_creation_commands() function, which
causes the parse node to be deparsed and returned as a JSON blob. This
patch also introduces a function to decode the JSON blob back into a
text string, possibly after being tweaked by the user code. A bunch of
DDL commands are implemented here, such as CREATE SCHEMA, CREATE TABLE,
and the like -- the basics.

Then we have a bunch more patches which add support for more commands.
In these patches you can see how the deparsing code for a certain
command can be written. Most are pretty simple, but interesting
examples such as CREATE FUNCTION are also included. We also have some
commands that are not merely create, such as ALTER..RENAME.

Patch 23 is the next interesting one -- it adds support for ALTER TABLE.
This one is a lot more involved, because deparsing ALTER TABLE
subcommands requires adding a call to collect each subcommand in
tablecmds.c itself. In order to implement this, I modified most
subcommand functions so that they return the OID of the affected object,
or the attribute number of the affected column. For example if you add
a constraint, the OID of the constraint is returned. This OID is
collected and added to the list of subcommands. At deparse time, the
collected commands can be deparsed back into JSON blobs as usual. Since
certain commands execute AlterTable internally, I had to add
"bracketing" calls to them, which set up a pseudo-ALTER TABLE context
onto which the subcommands can be added. For instance, CREATE INDEX,
CREATE VIEW and CREATE TABLESPACE MOVE are known to do this.

... then a bunch more boring commands are implemented ...

Finally, patch 36 adds support for GRANT and REVOKE deparsing. This one
is interesting because it's completely unlike the others. Here we don't
have a single OID of an affected object. I chose to support this by
exposing the InternalGrantStmt struct (in a new aclchk.h file), which we
can deparse easily into the familiar JSON format. (Of course, in an
patch earlier in the series I also had to modify event triggers so that
grant/revoke fire them as well, which currently they do not.)

There are no docs yet. This has been tested in the bidirectional
replication suite -- it works by saving the deparsed (SQL, not JSON)
command in a replicated table; the remote side executes the command when
it receives the tuple. Commands that fail to deparse sanely cause very
visible errors.

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