Re: deparsing utility commands

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: deparsing utility commands
Date: 2015-02-24 13:48:38
Message-ID: 20150224134838.GG5169@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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.)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-02-24 14:15:21 Re: Fillfactor for GIN indexes
Previous Message Sergey Shchukin 2015-02-24 13:42:06 Issue with a hanging apply process on the replica db after vacuum works on primary