Re: Simplify event trigger support checking functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simplify event trigger support checking functions
Date: 2022-10-07 16:43:31
Message-ID: CA+TgmoYbMq1EvcXMMk7gH-tdZ9XhAO2HLD7J4_s7LWKnz4ve_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 7, 2022 at 8:10 AM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> 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().

This doesn't seem like a good idea to me. If the function names give
the idea that you can decide whether new object types should support
event triggers or not, we could change them, or add better comments.
However, right now, you can't add a new object type and fail to update
these functions. With this change, that would become possible. And the
whole point of coding the functions in the way that they are was to
avoid that exact hazard. So I think we should leave the code the way
it is.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2022-10-07 16:48:49 Re: proposal: possibility to read dumped table's name from file
Previous Message Robert Haas 2022-10-07 16:32:39 Re: Avoid mix char with bool type in comparisons