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

Re: Command Triggers

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <greg(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Command Triggers
Date: 2012-01-20 19:59:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> For the creation case, RangeVarGetCreationNamespace should handle that.
> The code Dimitri quoted is wrong, but not that hard to fix.


> Unfortunately, the code he quoted for the ALTER case is also wrong,
> and harder to fix.  Until you've done the lookup you don't know which
> schema the referenced object is in.  And I don't care for the idea of
> doing the lookup twice, as (a) it'll be slower and (b) there are race
> cases where it will give the wrong answer, ie return an object other
> than the one the ALTER eventually acts on.

Oh. Yes.

> Really I think there is not any single point where you can put the
> command-trigger hook and be done.  In almost every case, the right
> place is going to be buried somewhere within the execution of the
> command.

I'm finally realizing it. I already introduced a structure called
CommandContextData to keep track of the current command elements we want
to pass down to command triggers, I think we're saying that this should
be a static variable that commands will need to be editing.

The main problem with that approach is that we will need to spread
calling the command trigger entry points to every supported command, I
wanted to avoid that first. It's no big deal though, as the API is
simple enough.

Expect a new patch made this way early next week.

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-20 20:24:50
Subject: Re: Checkpoint sync pause
Previous:From: Tom LaneDate: 2012-01-20 19:27:50
Subject: Re: Command Triggers

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