Simplify event trigger support checking functions

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

Responses

Browse pgsql-hackers by date

  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