Message-ID: <80f51c3c-1c3a-41aa-e5c3-0d07c6c7c217@enterprisedb.com>
Date: Sat, 17 Jun 2023 21:57:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.1
Subject: Re: [PATCH] ltree hash functions
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tommy Pavlicek <tommypav122@gmail.com>, pgsql-hackers@lists.postgresql.org
References: <CAEhP-W9ZEoHeaP_nKnPCVd_o1c3BAUvq1gWHrq8EbkNRiS9CvQ@mail.gmail.com>
 <ddb89eb3-bb8c-6687-2bdd-577549da0f46@enterprisedb.com>
 <2602028.1687025982@sss.pgh.pa.us>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <2602028.1687025982@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/80f51c3c-1c3a-41aa-e5c3-0d07c6c7c217%40enterprisedb.com>
Precedence: bulk


On 6/17/23 20:19, Tom Lane wrote:
> 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.
> 

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