Re: deparsing utility commands - Mailing list pgsql-hackers

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > Regardless, as I've tried to point out above, the
> > changes which I'm actually suggesting for this initial body of work are
> > just to avoid the parsetree and go based off of what the catalog has.
> > I'm hopeful that's a small enough and reasonable enough change to happen
> > during this commitfest.  I don't have any issue tabling the rest of the
> > discussion and future work based on that to a later time.
>
> At some point I did consider the idea that the CREATE cases of the
> deparse code could be usable without a parse tree.  For the specific
> case of deparsing a DDL command as it's being ran, it's important to
> have the parse tree: options such as IF EXISTS, OR REPLACE and others
> don't live in the catalogs and so they must be obtained from the parse
> tree.  I think it is possible to adjust some of the code so that it can
> run with a NULL parse tree, and set the options to empty in those cases;
> that should return a usable command to re-create the object.

Right, being able to run it with a NULL parse tree would absolutely work
for the use-cases that I'm thinking of.  I suggested somewhere up-thread
that those bits of information (IF EXISTS, OR REPLACE) might be possible
to pass in as independent arguments or through a compound argument (eg:
a List or struct or something), instead of coming from the parse tree,
but that's clearly something which could be done later.

> One point to bear in mind is that there is still some work left; and if
> I need to additionally add extra interfaces so that this code can be
> called from outside event triggers, I will not have any time to review
> other people's patches from the commitfest.  So here's my suggestion:
> let this be pushed with the current interfaces only, with an eye towards
> not adding obstacles to future support for a different interface.
> That's more in the spirit of incremental improvement than trying to cram
> everything in the initial commit.

I'm perfectly fine with having the initial commit of this work using the
existing interfaces and further that we only need one set of interfaces
for 9.5, but, for my part, I'd love to be able to build an extension on
9.5 which calls these functions and passes in a NULL parsetree.  Perhaps
that's wishful thinking at this part and maybe I'll have to wait til
9.6, but that's why I've brought this up.

> I'm thinking something like
>  SELECT * FROM pg_creation_commands({'pg_class'::regclass, 'sometable'::pg_class});
> would return a set of commands in the JSON-blob format that creates the
> table.  The input argument is an array of object addresses, so that you
> can request creation commands for multiple objects.  (It's not my
> intention to provide this functionality right away, but if somebody else
> wants to work on top of the current deparse patch, by my guest; if it
> proves simple enough we can still get it into 9.5 as part of this
> patch.)

I'm all for this, but it seems too late for it to get into 9.5.  I'd be
happy with just the functions existing and available to extensions for
9.5.
Thanks!
    Stephen