Tom Lane <tgl@sss.pgh.pa.us> writes:
> For the creation case, RangeVarGetCreationNamespace should handle that.
> The code Dimitri quoted is wrong, but not that hard to fix.
Ok.
> 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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
