Re: Command Triggers, v16 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Command Triggers, v16
Date
Msg-id 7291.1331905855@sss.pgh.pa.us
Whole thread Raw
In response to Re: Command Triggers, v16  (Andres Freund <andres@anarazel.de>)
Responses Re: Command Triggers, v16  (Andres Freund <andres@anarazel.de>)
Re: Command Triggers, v16  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
>> I tricked that in the grammar, the type is called cmdtrigger but I
>> though it wouldn't be a good choice for the SQL statement.

> Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am 
> squeamish.

Multi-word type names are a serious pain in the ass; they require
hackery in a lot of places.  We support the ones that the SQL spec
requires us to, but I will object in the strongest terms to inventing
any that are not required by spec.  I object in even stronger terms to
the incredibly klugy way you did it here.

If you think "cmdtrigger" isn't a good name maybe you should have
picked a different one to start with.

While I'm looking at the grammar ... it also seems like a serious
PITA from a maintenance standpoint that we're now going to have to
adjust the CREATE COMMAND TRIGGER productions every time somebody
thinks of a new SQL command.  Maybe we should drop this whole idea
of specifying which commands a trigger acts on at the SQL level,
and just have one-size-fits-all command triggers.  Or perhaps have
the selection be on the basis of strings that are matched to command
tags, instead of grammar constructs.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: foreign key locks, 2nd attempt
Next
From: Shigeru Hanada
Date:
Subject: Re: Proposal: Create index on foreign table