Re: Command Triggers, v16

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Thom Brown <thombrown(at)gmail(dot)com>
Subject: Re: Command Triggers, v16
Date: 2012-03-16 15:06:35
Message-ID: m2aa3g7fgk.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

Ok, it's so klugy that removing the support from the parser is going to
be easy.

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

Well, I think it's a good internal name. I'm not too sure about exposing
it, the only reason why it's a good name is because it's a single not
too long word, after all. Not very “SQLish”.

I'm putting cmdtrigger as the user visible name in the next version of
the patch, if you come up with something potentially more user friendly
feel free to suggest.

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

The only advantage of doing it this way is giving the user an early
error when he's trying to attach to a non-supported command. I wouldn't
want to remove that list only to find myself adding a list of non
supported commands so that we can still refuse creating the useless
command trigger.

And as Andres said, adding command trigger support to a new command
isn't exactly transparent (it's still mostly mechanical though), so that
does not seems so big a pain to me. Of course I have been having my head
in there for a long time now…

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-16 15:16:14 Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my
Previous Message Tom Lane 2012-03-16 14:20:31 Re: Syntax error and reserved keywords