From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Simplify event trigger support checking functions |
Date: | 2022-10-07 12:10:44 |
Message-ID: | 2ce5758d-a1a8-bcc1-4bd7-381307cc6cbe@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
We have in event_trigger.c two functions
EventTriggerSupportsObjectType() and EventTriggerSupportsObjectClass()
that return whether a given object type/class supports event triggers.
Maybe there was a real differentiation there once, but right now it
seems to me that *all* object types/classes support event triggers,
except: (1) shared objects and (2) event triggers themselves. I think
we can write that logic more explicitly and compactly and don't have to
give the false illusion that there is a real choice to be made by the
implementer here.
The only drawback in terms of code robustness is that someone adding a
new shared object type would have to remember to add it to
EventTriggerSupportsObjectType(). Maybe we could add a "object type is
shared" function somehow, similar to IsSharedRelation(), to make that
easier. OTOH, someone doing that would probably go around and grep for,
say, OBJECT_TABLESPACE and find relevant places to update that way.
Thoughts?
Attachment | Content-Type | Size |
---|---|---|
0001-Simplify-event-trigger-support-checking-functions.patch | text/plain | 6.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Denis Laxalde | 2022-10-07 13:08:05 | [PATCH] Reset single-row processing mode at end of pipeline commands queue |
Previous Message | Magnus Hagander | 2022-10-07 12:07:34 | Re: future of serial and identity columns |