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. regards, tom lane
