Re: deparsing utility commands
От | Andres Freund |
---|---|
Тема | Re: deparsing utility commands |
Дата | |
Msg-id | 20150224142458.GA19861@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: deparsing utility commands (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: