Re: Command Triggers, v16 - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers, v16
Date
Msg-id m28vinnp1d.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Command Triggers, v16  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Command Triggers, v16  (Thom Brown <thombrown@gmail.com>)
Re: Command Triggers, v16  (Robert Haas <robertmhaas@gmail.com>)
Re: Command Triggers, v16  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Dimitri's proposed behavior would be advantageous if you have an ANY
> trigger that wants to "take over the world" and make sure that nobody
> else can run before it.  I think, though, that's not a case we want to
> cater to - all of this stuff requires superuser privileges anyway, so
> we should assume that the DBA knows what he's doing.  So +1 for making

What about extensions?

One use case would be for londiste/slony/bucardo to rewrite the command
and queue its text, that will be done in C and should probably be done
first. Using an ANY command trigger means that code will run before user
specific code (or likewise after it).

As I said it's not that clear in my head, but when thinking about
command trigger and extensions, it could be better to impose an
arbitrary order here.

> it strictly alphabetical, as we do with other triggers.  Everything
> that can be done under Dimitri's proposal can also be done in that
> scheme, but the reverse is not true.

That's true too. I'm just not sure how much it applies to code installed
by the DBA as opposed to written by the DBA. I'll be happy to edit the
patch to melt both lists if that's the decision, it's not hard to do so.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Remove dead assignment
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Remove dead assignment