On Tue, Oct 10, 2023 at 9:32 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Tommy Pavlicek <tommypav...@gmail.com> writes: > > I did notice one further potential bug. When creating an operator and > > adding a commutator, PostgreSQL only links the commutator back to the > > operator if the commutator has no commutator of its own, but the > > create operation succeeds regardless of whether this linkage happens. > > > In other words, if A and B are a pair of commutators and one creates > > another operator, C, with A as its commutator, then C will link to A, > > but A will still link to B (and B to A). It's not clear to me if this > > in itself is a problem, but unless I've misunderstood something > > operator C must be the same as B so it implies an error by the user > > and there could also be issues if A was deleted since C would continue > > to refer to the deleted A. > > Yeah, it'd make sense to tighten that up. Per the discussion so far, > we should not allow an operator's commutator/negator links to change > once set, so overwriting the existing link with a different value > would be wrong. But allowing creation of the new operator to proceed > with a different outcome than expected isn't good either. I think > we should start throwing an error for that. > > regards, tom lane
Thanks. I've added another patch (0002-require_unused_neg_com-v1.patch) that prevents using a commutator or negator that's already part of a pair. The only other changes from my email yesterday are that in the ALTER command I moved the post alter hook to after OperatorUpd and the addition of tests to verify that we can't use an existing commutator or negator with the ALTER command. I believe this can all be looked at again. Cheers, Tommy
0002-require_unused_neg_com-v1.patch
Description: Binary data
0003-refactor-v3.patch
Description: Binary data
0001-bug-fixes-v3.patch
Description: Binary data
0004-alter_op-v4.patch
Description: Binary data