Re: Command Triggers - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers
Date
Msg-id m2r4yygg2z.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Command Triggers  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Command Triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: Should we add crc32 in libpgport?
Next
From: Thomas Munro
Date:
Subject: Re: SKIP LOCKED DATA