Re: Event Triggers: adding information - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Event Triggers: adding information
Date
Msg-id CA+TgmobaEsXomLihUy4KgTNqz95mf8S3bN3Lcs5oEddPpTkPew@mail.gmail.com
Whole thread Raw
In response to Re: Event Triggers: adding information  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Event Triggers: adding information
List pgsql-hackers
On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Andres Freund escribió:
>>> 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 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.
>
> Well, that burden already exists for non-utility statements --- why
> should utility statements get a pass?  Other than that we tend to invent
> new utility syntax freely, which might be a good thing to discourage
> anyhow.

My concerns are that (1) it will slow down the addition of new
features to PostgreSQL by adding yet another barrier to commit and (2)
it won't be get enough use or regression test coverage to be, or
remain, bug-free.

There may be other concerns with respect to the patch-as-proposed, but
those are my high-level concerns.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Phil Sorber
Date:
Subject: Re: [WIP] pg_ping utility
Next
From: Boszormenyi Zoltan
Date:
Subject: Contrib PROGRAM problem