From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: deparsing utility commands |
Date: | 2015-02-24 14:24:58 |
Message-ID: | 20150224142458.GA19861@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-02-24 10:48:38 -0300, Alvaro Herrera 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.
Yep.
> 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.
+1
> 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 think that'd be usefuful functionality, but I can't see it being
realistic for 9.5 unless somebody starts working on it right now with
full force.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Sawada Masahiko | 2015-02-24 14:28:43 | Re: Proposal : REINDEX xxx VERBOSE |
Previous Message | Tomas Vondra | 2015-02-24 14:15:21 | Re: Fillfactor for GIN indexes |