From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Event Triggers: adding information
Date: Fri, 18 Jan 2013 15:22:55 -0300
Message-ID: <20130118182255.GG4063@alvh.no-ip.org> (raw)
In-Reply-To: <20130118180326.GM29501@alap2.anarazel.de>
References: <m2ehhjbf48.fsf@2ndQuadrant.fr>
<20130118013334.GE3074@awork2.anarazel.de>
<CA+TgmobU2xZ7hPh24HYmvSxO7kbXUtY57bePX+mpB5aywTz2HA@mail.gmail.com>
<20130118140721.GA29501@alap2.anarazel.de>
<CA+TgmoYL9o2MBjWdaUcRqj_B5J=k63rq8vKkcszDyH4CDT1AKQ@mail.gmail.com>
<20130118154732.GE29501@alap2.anarazel.de>
<CA+Tgmoa-p-texRBzgetFgvaKwWJJ=a3XBCWMOQdg17aWtrDPNg@mail.gmail.com>
<20130118170857.GK29501@alap2.anarazel.de>
<10183.1358531053@sss.pgh.pa.us>
<20130118180326.GM29501@alap2.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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/...
>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, andres@2ndquadrant.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, dimitri@2ndquadrant.fr, simon@2ndquadrant.com
Subject: Re: Event Triggers: adding information
In-Reply-To: <20130118182255.GG4063@alvh.no-ip.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox