Re: deparsing utility commands - Mailing list pgsql-hackers

On 2015-02-21 14:51:32 -0500, Stephen Frost wrote:
> It'd be *really* nice to be able to pass an object identifier to some
> function and get back the CREATE (in particular, though perhaps DROP, or
> whatever) command for it.  This gets us *awful* close to that without
> actually giving it to us and that's bugging me.  The issue is the
> parsetree, which I understand may be required in some cases (ALTER,
> primairly, it seems?), but isn't always.
> The USING and WITH CHECK quals can be extracted from the polForm also,
> of course, it's what psql and pg_dump are doing, after all.
> 
> So, why depend on the parsetree?  What about have another argument which
> a user could use without the parsetree, for things that it's absolutely
> required for today (eg: ALTER sub-command differentiation)?

I'm really not wild about pretty massively expanding the scope at the
eleventh hour.  There's a fair number of commands where this the
deparsing command will give you a bunch of commands - look at CREATE
TABLE and CREATE SCHEMA ... for the most extreme examples. For those
there's no chance to do that without the parse tree available.

Yes, it might be possible to use the same code for a bunch of minor
commands, but not for the interesting/complex stuff.

> Maybe that's possible and maybe it isn't, but at least for the CREATE
> cases we should be able to avoid forcing a user to provide a built
> parsetree, and that'd be *really* nice and open up this feature to
> quite a few other use-cases that I can think of.  I'd further suggest
> that we provide these command to the SQL level, and then have a
> wrapper which will take the name of an object, resolve it to Oid, and
> then pass back the CREATE command for it.

I think this is a different feature that might end up sharing some of
the infrastructure, but not more.

> For as much commentary as there has been about event triggers and
> replication and BDR, and about how this is going to end up being a
> little-used side-feature, I'm amazed that there has been very little
> discussion about how this would finally put into the backend the ability
> to build up CREATE commands for objects and remove the need to use
> pg_dump for that (something which isn't exactly fun for GUI applications
> and other use-cases).

I don't think it's all that related, so I'm not surprised. If you
execute a CREATE TABLE(id serial primary key); you'll get a bunch of
commands with this facility - it'd be much less clear what exactly shall
be dumped in the case of some hypothetical GUI when you want to dump the
table.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services