| 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: | Whole Thread | Raw Message | 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 |