Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
