On 6/17/23 20:19, Tom Lane wrote:
> Tomas Vondra <tomas.von...@enterprisedb.com> writes:
>> I guess the "correct" solution would be to extend ALTER OPERATOR. I
>> wonder why it's not supported - it's clearly an intentional decision
>> (per comment in AlterOperator). So what might break if this changes for
>> an existing operator?
>
> This code was added by commit 321eed5f0. The thread leading up to
> that commit is here:
>
> https://www.postgresql.org/message-id/flat/3348985.V7xMLFDaJO%40dinodell
>
> There are some nontrivial concerns in there about breaking the
> semantics of existing exclusion constraints, for instance. I think
> we mostly rejected the concern about invalidation of cached plans
> as already-covered, but that wasn't the only problem.
>
> However, I think we could largely ignore the issues if we restricted
> ALTER OPERATOR to only add commutator, negator, hashes, or merges
> properties to operators that lacked them before --- which'd be the
> primary if not only use-case anyway. That direction can't break
> anything.
>
Sound reasonable.
Tommy, are you interested in extending ALTER OPERATOR to allow this,
which would also allow fixing the ltree operator?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
