Horton

Re: Command Triggers, patch v11

Dimitri Fontaine <dimitri@2ndquadrant.fr>

View thread
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-27T21:22:03Z
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.

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.

I agree with the analysis…

> 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.

But had been (too easily) convinced not to take that route.  You changed
my mind already, I'll see about changing the code too tomorrow (a cold
is having me out of steam for tonight).

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support