Date: Fri, 18 Jan 2013 15:22:55 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
	Dimitri Fontaine <dimitri@2ndquadrant.fr>,
	Simon Riggs <simon@2ndquadrant.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Event Triggers: adding information
Message-ID: <20130118182255.GG4063@alvh.no-ip.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <20130118180326.GM29501@alap2.anarazel.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andres Freund escribi=F3:
> 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.
>=20
> 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/d2996303c7bc6daa08cef23e3d5e07c3=
afb11191/src/backend/utils/adt/ddl_rewrite.c
>=20
> 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.

--=20
=C1lvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers