pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Thom Brown <thom@linux.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Command Triggers, patch v11
Date: Sun, 04 Mar 2012 19:08:18 +0100
Message-ID: <m2y5rgck8d.fsf@2ndQuadrant.fr> (raw )
In-Reply-To: <18852.1330376038@sss.pgh.pa.us >
References: <m24nufq466.fsf@2ndQuadrant.fr >
<CAA-aLv5H5_ALMRZFatX-wDEz1meMvQVJOsBBFTYox65jzAoN5Q@mail.gmail.com >
<m2y5rrktqi.fsf@2ndQuadrant.fr >
<CAA-aLv6kfradv_+LVC=TyS=UR3PD2vuMsS++A8BbvSW9H6mQ_g@mail.gmail.com >
<CAA-aLv4_dfsAKS_AfReYw86KTkskhDDWycMc+Jb0vprc-OjnsA@mail.gmail.com >
<CAA-aLv5i8tOyCivP6fYNgMUL2bi3atxdX-RBh791G7jr=ehGmA@mail.gmail.com >
<CAA-aLv6AUdGFBA4=qkKExHxSiJ3fybV71S=KHGP2uNgJ2OV7uA@mail.gmail.com >
<CAA-aLv6qDiz3pdxwZwMk_ABmERSm1sOCfZ4CMiy4qVJZYb=o6g@mail.gmail.com >
<CAA-aLv7G0WLrQ3fgZ76DybrEmgGriJ-+otgsf6TyOrEcJfWcFw@mail.gmail.com >
<CAA-aLv5aEwUVQ1zOCNvDzzPTZ71Z5BGSuZ5+LKWTktbUz_3tYw@mail.gmail.com >
<m2zkc5of8k.fsf@2ndQuadrant.fr >
<CAA-aLv5tuh9RKNmgCnxWr8jdUOi0EeYix32GC2Pxvr=7DUD+JQ@mail.gmail.com >
<CAA-aLv7ba=+0G_5Qs97u-5yBGvK=iHAGdR=8P7q9CiBT8hW8Jg@mail.gmail.com >
<m2ipis2hum.fsf@2ndQuadrant.fr >
<18852.1330376038@sss.pgh.pa.us >
Tom Lane <tgl@sss.pgh.pa.us> writes:
> FWIW, I agree with Thom on this. If we do it as you suggest, I
> confidently predict that it will be less than a year before we seriously
> regret it. Given all the discussion around this, it's borderline insane
> to believe that the set of parameters to be passed to command triggers
> is nailed down and won't need to change in the future.
>
> As for special coding of support, it hardly seems onerous when every
> language that has triggers at all has got some provision for the
> existing trigger parameters. A bit of copying and pasting should get
> the job done.
So, for that to happen I need to add a new macro and use it in most call
sites of CALLED_AS_TRIGGER(fcinfo). That includes the setup switch in
src/pl/plpgsql/src/pl_comp.c doCompile() and plpgsql_call_handler() for
starters.
Let's call the macro CALLED_AS_COMMAND_TRIGGER(fcinfo), and I would
extend CommandContextData to be a Node of type CommandTriggerData, that
needs to be added to the NodeTag enum as T_CommandTriggerData.
With that in place I can stuff the data into the function's call context
(via InitFunctionCallInfoData) then edit the call handlers of included
procedure languages until they are able to init their language variables
with the info.
Then, do we want the command trigger functions to return type trigger or
another specific type? I guess we want to forbid registering any
function as a command trigger?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
view thread (115+ messages) latest in thread
Message-ID: <m2y5rgck8d.fsf@2ndQuadrant.fr>
Permalink: ../m2y5rgck8d.fsf@2ndQuadrant.fr/
Also on: postgresql.org/message-id/m2y5rgck8d.fsf@2ndQuadrant.fr
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: dimitri@2ndQuadrant.fr, tgl@sss.pgh.pa.us, thom@linux.com
Subject: Re: Command Triggers, patch v11
In-Reply-To: <m2y5rgck8d.fsf@2ndQuadrant.fr>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox