On Wed, Mar 28, 2012 at 4:12 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.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
