From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Tommy Pavlicek <tommypav122(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] ltree hash functions |
Date: | 2023-06-17 18:19:42 |
Message-ID: | 2602028.1687025982@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2023-06-17 18:29:24 | Assert while autovacuum was executing |
Previous Message | Tomas Vondra | 2023-06-17 17:40:30 | Re: [PATCH] ltree hash functions |