Re: Add CREATE support to event triggers Reply-To:

<CA+TgmoaYO1E2TJjEfRvhGq6TMgpYhg_4LOy_fwRZL8TxXgFSGA@mail.gmail.com>

Robert Haas wrote:

> What does the colon-space in %{definition: }s mean?

It means it expects the "definition" element to be a JSON array, and
that it will format the elements by separating them with a space.  In
other DDL commands, there are things like %{table_element:, }s  which
means to separate with comma-space.  (In CREATE TABLE, these
table_elements might be column definitions or constraints).  It's a
pretty handy way to format various things.  The separator is arbitrary.

> In general, it seems like you're making good progress here, and I'm
> definitely happier with this than with previous approaches, but I'm
> still concerned about how maintainable it's going to be.

Thanks.

There are three parts to this code.  Two of them are infrastructure to
make it all work: one is the code to support creation of the JSON
values, that is, functions to add new elements to the tree that's
eventually going to become JSON (this is the approximately 640 lines at
the top of deparse_utility.c).  The second one is the "expand"
functionality, i.e. what turns the JSON back into text (bottom 700 lines
in event_trigger.c).  Both are fairly static now; while I was writing it
initially there was a lot of churn until I found an interface that made
the most sense.  I don't think these parts are going to cause much
trouble.

The third part is the bits that take a parse node and determine what
elements to put into JSON.  This is the part that is going to show the
most churn as DDL is modified.  But it's not a lot of code; for
instance, deparsing a CREATE SCHEMA node takes 30 lines.
90 lines to deparse CREATE RULE.
80 lines for CREATE INDEX.
280 lines of shared code for ALTER SEQUENCE and CREATE SEQUENCE.

I don't think we should be worried about there being a lot of extra code
to write as DDL is added or modified.  I do share your concern that
we're going to *forget* to write these things in the first place, unless
we do something to avoid that problem specifically.

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