Horton

Re: Command Triggers, patch v11

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-27T20:53:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.

  2. Remove useless const qualifier

  3. Make executor's SELECT INTO code save and restore original tuple receiver.

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Thom Brown <thom@linux.com> writes:
>> I've got a question regarding the function signatures required for
>> command triggers, and apologies if it's already been discussed to
>> death (I didn't see all the original conversations around this).
>> These differ from regular trigger functions which don't require any
>> arguments, and instead use special variables.  Why aren't we doing the
>> same for command triggers?  So instead of having the parameters

> Basically so that we don't have to special code support for each and
> every language out there.

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.

			regards, tom lane