Re: Should we allow ALTER OPERATOR CLASS to ADD/DROP operators and procedures?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
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:58:39
Message-ID: 1448820.1738947519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> On 2/7/25 01:15, Tom Lane wrote:
>> 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?

Yes. AFAIR (didn't check the code) the only difference between
pg_amop/pg_amproc entries made in CREATE OPERATOR CLASS and those
made in ALTER OPERATOR FAMILY is that the former have a dependency
on the opclass while the latter have a dependency on the opfamily.
That won't matter unless you do DROP OPERATOR CLASS without
dropping the rest of the family.

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

Seems better to use CREATE OR REPLACE FUNCTION to do that redirection,
so that it happens during ALTER EXTENSION ... UPDATE rather than
whenever the updated shlib is installed.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-02-07 17:01:33 Draft back-branch release notes are up
Previous Message Zhang Mingli 2025-02-07 16:50:47 Re: Proposal to CREATE FOREIGN TABLE LIKE