Re: deparsing utility commands - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: deparsing utility commands
Date
Msg-id 20150224134838.GG5169@alvh.no-ip.org
Whole thread Raw
In response to Re: deparsing utility commands  (Stephen Frost <sfrost@snowman.net>)
Responses Re: deparsing utility commands
Re: deparsing utility commands
Re: deparsing utility commands
List pgsql-hackers
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.

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 thinking something likeSELECT * 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.)

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



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Allow "snapshot too old" error, to prevent bloat
Next
From: Tomas Vondra
Date:
Subject: Re: Fillfactor for GIN indexes