From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should we allow ALTER OPERATOR CLASS to ADD/DROP operators and procedures? |
Date: | 2025-02-07 16:24:21 |
Message-ID: | 2792c089-dae2-4ca1-9225-bdf362c5b906@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/7/25 01:15, Tom Lane wrote:
> Tomas Vondra <tomas(at)vondra(dot)me> writes:
>> Which is why PostGIS devs chose a different path - updating the catalogs
>> to modify the opclass definition [3], using this script [4].
>
>> That's a bit ... terrifying.
>
> Indeed. Did it not occur to them to use ALTER OPERATOR FAMILY?
>
No, it did not. But that may be my fault - I've reported the bug, and
I've been discussing possible fixes with them, and it didn't occur to me
either :-(
It seems quite non-intuitive to fix a bug in OPERATOR CLASS by doing
ALTER OPERATOR FAMILY.
> The end result of doing so is that the added opfamily members
> wouldn't have been bound tightly to the opclass, but that does
> not seem like a huge deal in context. They'd still have worked
> fine AFAIK.
>
I haven't tried but I assume you're suggesting adding the MERGE proc to
the opfamily would be enough for the opclass to pick it up?
However, I'm not sure this would be a complete fix, because what would
they do with the existing ADD_VALUE proc? Sure, they could just tweak
the C code to "redirect" the call to the built-in one. But that requires
the MERGE proc being defined, so it'd crash if someone installs the new
version .so but doesn't do ALTER EXTENSION ... UPDATE.
regards
--
Tomas Vondra
From | Date | Subject | |
---|---|---|---|
Next Message | Srirama Kucherlapati | 2025-02-07 16:50:30 | RE: AIX support |
Previous Message | Peter Eisentraut | 2025-02-07 15:53:46 | Re: Index AM API cleanup |