Horton

Re: Command Triggers, patch v11

Dimitri Fontaine <dimitri@2ndquadrant.fr>

View thread
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Thom Brown <thom@linux.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-27T19:31:45Z
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.

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.

> Disadvantages are that there's more maintenance overhead for
> supporting multiple languages using special variables.

Lots of, so I've been told, enough of it for not taking this choice
seriously.  I'll admit I didn't personally looked at what it would
entail implementation wise.

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