Andres Freund escribió: > On 2013-01-18 12:44:13 -0500, Tom Lane wrote:
> > 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. I looked at that code back then and didn't like it very much. The problem I see (as Robert does, I think) is that it raises the burden when you change the grammar -- you now need to edit not only gram.y, but the ddl_rewrite.c stuff to ensure your new thing can be reverse-parsed. One idea I had was to add annotations on gram.y so that an external (Perl?) program could generate the ddl_rewrite.c equivalent, without forcing the developer to do it by hand. Another problem is what Tom mentions: there are internal options that cannot readily be turned back into SQL. We would have to expose these at the SQL level somehow; but to me that looks painful because we would be offering users the option to break their systems by calling commands that do things that should only be done internally. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
