Re: Deparsing DDL command strings - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> IMHO, it should be our explicit goal for clients not to need to parse
> any SQL at all.  I think that the communication between the server and
> event triggers should be accomplished using magic variables.  If the

+1 on that. There's a but.

> data is too complex to be structured that way, then I think we should
> use an established serialization format such as XML or (my personal
> preference) JSON for which many parsers already exist.  If we pass
> sanitized SQL, then everyone who wants to do anything complicated will
> need a parser for
> sanitized-SQL-as-generated-by-the-PostgreSQL-event-trigger-mechanism,
> and I think that's likely to be strictly worse than using one of the
> serialization methods that already exists and is well understood.

That's not an easy task by any means, we're talking about inventing a
stable alternative to the parse tree format (nodeToString) so that we
can whack the parsenodes as much as we need and still produce something
compatible for our users. Well at least we've already heard about more
than one use case, e.g. exposing the parser for syntax highlighting…

Now, if all you want to do is replay the exact same DDL on another
PostgreSQL instance, and if you happen to trust the master's server,
then the command string I'm currently spitting out is exactly what you
need. And having the more generalized representation of the parser data
would only mean that the trigger now has to rewrite the command string
itself.

> There's a careful line to be walked here, because in order for event
> triggers to be useful, we're going to have to pass them information -
> and the way we do that becomes part of the API, and might get broken
> by future changes.  That sucks, but there's nothing we can do to

+1 here, again, we're on the same line, just having different use cases
in mind it seems.

> completely prevent it except not have event triggers at all, and I
> want event triggers, and so do many other people.  What we can and I
> think must do is minimize the difficulty of writing and maintaining
> event triggers, and that means making the API as clean as possible.
> Like Tom, I'm very skeptical that this is the right horse to bet on.

I would thing that having one doesn't preclude having the other, and
while I hear Tom and you saying that it's a lot of maintenance work down
the road to have the command string, I'm highly skeptical of being able
to produce that external stable (enough) parser format in a way that
impose less code maintenance down the road.

Also, I'm thinking that publishing the normalized command string is
something that must be maintained in the core code, whereas the external
stable format might be done as a contrib extension, coded in C, working
with the Node *parsetree. Because it needs to ouput a compatible format
when applied to different major versions of PostgreSQL, I think it suits
quite well the model of C coded extensions.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support