Skip site navigation (1) Skip section navigation (2)

Re: Command Triggers patch v18

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Command Triggers patch v18
Date: 2012-03-28 11:16:42
Message-ID: CA+Tgmoatv-OAHD8pVDQ0FrRDSt-WWGKNomjB0FbHw+BzVDMegg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Mar 28, 2012 at 4:12 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> I think BEFORE command triggers ideally should run
>>> * before permission checks
>>> * before locking
>>> * before internal checks are done (nameing conflicts, type checks and such)
>>
>> It is possible to do this, and it would actually be much easier and
>> less invasive to implement than what Dimitri has done here, but the
>> downside is that you won't have done the name lookup either.
>
> There's a trade-off decision to take here, that was different in
> previous versions of the patch. You can either run the trigger very
> early or have specific information details.
>
> The way to have both and keep your sanity, and that was implemented in
> the patch, is to have ANY command triggers run before the process
> utility big switch and provide only the command tag and parse tree, and
> have the specific triggers called after permission, locking and internal
> checks are done.
>
> I've been asked to have a single call site for ANY and specific
> triggers, which means you can't have BEFORE triggers running either
> before or after those steps.
>
> Now I can see why implementing that on top of the ANY command feature is
> surprising enough for wanting to not do it this way. Maybe the answer is
> to use another keyword to be able to register command triggers that run
> that early and without any specific information other than the command
> tag.

Yeah, I think so.  I objected to the way you had it because of the
inconsistency, not because I think it's a useless place to fire
triggers.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Albe LaurenzDate: 2012-03-28 12:07:21
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Previous:From: Thom BrownDate: 2012-03-28 11:00:40
Subject: Re: pgsql_fdw, FDW for PostgreSQL server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group