Re: Simplify event trigger support checking functions

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simplify event trigger support checking functions
Date: 2022-10-12 06:55:30
Message-ID: 82c9a3d1-915d-7214-29de-a72d0abb6c82@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07.10.22 18:43, Robert Haas wrote:
> 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.

I don't think just adding an entry to these functions is enough to make
event trigger support happen for an object type. There are other places
that need changing, and really you need to write a test to check it. So
I didn't think these functions provided any actual value. But I'm not
too obsessed about it if others feel differently.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-10-12 07:04:04 Re: create subscription - improved warning message
Previous Message John Naylor 2022-10-12 06:53:05 Re: meson PGXS compatibility