On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-01-18 11:42:47 -0500, Robert Haas wrote:
> >> I'm having trouble following this. Can you restate? I wasn't sure
> >> what you meant by libpqdump. I assumed you were speaking of a
> >> parsetree->DDL or catalog->DDL facility.
>
> > Yea, that wasn't really clear, sorry for that.
>
> > What I was trying to say that I think doing parstree->text conversion
> > out of tree is noticeably more complex and essentially places a higher
> > maintenance burden on the project because
>
> Ah. That's not pg_dump's job though, so you're choosing a bad name for
> it.
I really only mentioned libpgdump because the object access hooks at the
moment only get passed the object oid and because Robert doubted the
need for deparsing the parsetrees in the past. Without the parsetree you
obviousl cannot deparse the parsetree ;)
I do *not* think that using something that reassembles the statement
solely based on the catalog context is a good idea.
> What I think you are really talking about is extending the
> deparsing logic in ruleutils.c to cover utility statements. Which is
> not a bad plan in principle; we've just never needed it before. It
> would be quite a lot of new code though.
Yes, I think that is the only realistic approach at providing somewhat
unambigious SQL to replicate DDL.
> An issue that would have to be thought about is that there are assorted
> scenarios where we generate "parse trees" that contain options that
> cannot be generated from SQL, so there's no way to reverse-list them
> into working SQL. But often those hidden options are essential to know
> what the statement will really do, so I'm not sure ignoring them will be
> a workable answer for replication purposes.
Dimitri's earlier patches had support for quite some commands via
deparsing and while its a noticeable amount of code it seemed to work
ok.
The last revision I could dig out is
https://github.com/dimitri/postgres/blob/d2996303c7bc6daa08cef23e3d5e07c3afb11191/src/backend/utils/adt/ddl_rewrite.c
I think some things in there would have to change (e.g. I doubt that its
good that EventTriggerData is involved at that level) but I think it
shows very roughly how it could look.
Greetings,
Andres
--Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services