Re: Command Triggers
Dimitri Fontaine <dimitri@2ndquadrant.fr>
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Greg Smith <greg@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@commandprompt.com>
Date: 2012-01-17T21:43:48Z
Lists: pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > Robert Haas <robertmhaas@gmail.com> writes: >> But on the flip side, I think we're generally a bit more flexible >> about exposing things via C than through the procedural languages. > > Then as Andres proposed, a new function would be available to get the > value, we're not changing the trigger procedure function API in case the > language is C… I've been updating my github branch with a patch that provides the parsetree to C coded command trigger functions only, as their 5th argument, of type INTERNAL (so that only C coded procs apply). https://github.com/dimitri/postgres/compare/master...command_triggers I still have some cleaning to do before to prepare the next patch version, such as documentation updating and dealing with rewrites of CHECK and DEFAULT column constraints in CREATE TABLE. I had to add support for the T_A_Const parser node, and now I'm about to see about adding support for the T_A_Expr one, but I can't help to wonder how the rewriter could work without them. What is this simple thing I'm missing here, if any? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support