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
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
In response to
pgsql-hackers by date
|Next:||From: Peter Geoghegan||Date: 2012-03-28 09:47:49|
|Subject: Re: Re: pg_stat_statements normalisation without invasive
changes to the parser (was: Next steps on pg_stat_statements normalisation)|
|Previous:||From: Thom Brown||Date: 2012-03-28 07:39:18|
|Subject: Re: pgsql_fdw, FDW for PostgreSQL server|