On Wed, Mar 28, 2012 at 4:12 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
