Re: Event Triggers: adding information

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event Triggers: adding information
Date: 2013-01-18 18:26:51
Message-ID: 20130118182651.GO29501@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-01-18 15:22:55 -0300, Alvaro Herrera wrote:
> 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.

Yea, but thats nothing new, you already need to do all that for normal
SQL. Changes that to the grammar that don't involve modifying ruleutils.c et
al. are mostly trivial enough that this doesn't really place that much of a
burden.

And I yet to hear any other proposal of how to do this?

> 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.

Hm. Which options are you two thinking of right now?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-18 18:46:18 Re: in-catalog Extension Scripts and Control parameters (templates?)
Previous Message Jeff Davis 2013-01-18 18:24:38 Re: 9.3 Pre-proposal: Range Merge Join