Обсуждение: Is there a way to detect that code is inside CREATE EXTENSION?
I'm working with an event trigger that fires on ALTER TABLE and regenerates certain objects, but unfortunately those objects end up being owned by any extensions that run ALTER TABLE and any subsequent alterations fail to regenerate because they are owned by that extension.
Ideally, I'd like to be able to detect inside my trigger if I'm being called from CREATE EXTENSION or not, but I can't find any obvious way to detect that. I hope this isn't obvious and I just missed something in the documentation. Does anyone have any pointers or hacks they know of that can accomplish this?
Thanks,
-Michel
Michel Pelletier <pelletier.michel@gmail.com> writes:
> I'm working with an event trigger that fires on ALTER TABLE and regenerates
> certain objects, but unfortunately those objects end up being owned by any
> extensions that run ALTER TABLE and any subsequent alterations fail to
> regenerate because they are owned by that extension.
> Ideally, I'd like to be able to detect inside my trigger if I'm being
> called from CREATE EXTENSION or not, but I can't find any obvious way to
> detect that.
At the C-code level you can check the creating_extension global variable,
or maybe better look at the in_extension fields of CollectedCommands.
I don't think we expose that state at the SQL level, but it's pretty
hard to make a useful event trigger without writing any C ...
regards, tom lane
On Tue, Dec 13, 2022 at 7:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Michel Pelletier <pelletier.michel@gmail.com> writes: > > I'm working with an event trigger that fires on ALTER TABLE and regenerates > > certain objects, but unfortunately those objects end up being owned by any > > extensions that run ALTER TABLE and any subsequent alterations fail to > > regenerate because they are owned by that extension. > > > Ideally, I'd like to be able to detect inside my trigger if I'm being > > called from CREATE EXTENSION or not, but I can't find any obvious way to > > detect that. > > At the C-code level you can check the creating_extension global variable, > or maybe better look at the in_extension fields of CollectedCommands. > > I don't think we expose that state at the SQL level, but it's pretty > hard to make a useful event trigger without writing any C ... AFAICS it's exposed in pg_event_trigger_ddl_commands().in_extension.
At the C-code level you can check the creating_extension global variable,
or maybe better look at the in_extension fields of CollectedCommands.
That was the hint I needed, looks like pg_event_trigger_ddl_commands() has an in_extension boolean that seems like it will do what I need? If I understand you correctly that's what you're referring to with CollectedCommands. Testing it now but that looks like the answer for me, if any of those are true then I can just skip the regeneration.
-Michel