Re: deparsing utility commands

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: deparsing utility commands
Дата
Msg-id 20150224134838.GG5169@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: deparsing utility commands  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: deparsing utility commands  (Andres Freund <andres@2ndquadrant.com>)
Re: deparsing utility commands  (Ryan Pedela <rpedela@datalanche.com>)
Re: deparsing utility commands  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: Allow "snapshot too old" error, to prevent bloat
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Fillfactor for GIN indexes