Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
Date
Msg-id 447166.1696969927@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges  (Tommy Pavlicek <tommypav122@gmail.com>)
Responses Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
List pgsql-hackers
Tommy Pavlicek <tommypav122@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



pgsql-hackers by date:

Previous
From: Tommy Pavlicek
Date:
Subject: Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges
Next
From: David Steele
Date:
Subject: Re: The danger of deleting backup_label