Andres Freund <and...@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. 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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
