From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
cc: Tommy Pavlicek <tommypav122@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] ltree hash functions
In-reply-to: <ddb89eb3-bb8c-6687-2bdd-577549da0f46@enterprisedb.com>
References: <CAEhP-W9ZEoHeaP_nKnPCVd_o1c3BAUvq1gWHrq8EbkNRiS9CvQ@mail.gmail.com> <ddb89eb3-bb8c-6687-2bdd-577549da0f46@enterprisedb.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@enterprisedb.com>
	message dated "Sat, 17 Jun 2023 19:40:30 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2602027.1687025982.1@sss.pgh.pa.us>
Date: Sat, 17 Jun 2023 14:19:42 -0400
Message-ID: <2602028.1687025982@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2602028.1687025982%40sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@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.

			regards, tom lane