Re: Command Triggers patch v18 - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers patch v18
Date
Msg-id 87398txhxg.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Command Triggers patch v18  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Command Triggers patch v18
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Next
From: Peter Geoghegan
Date:
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)