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.
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 |