Re: deparsing utility commands

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

In response to

Browse pgsql-hackers by date

  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