Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
