Re: operator dependency of commutator and negator

Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> On Wed, Sep 29, 2010 at 11:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm not sure that fixing this case is worth the amount of work it'd
>> take. How often do you drop just one member of a commutator pair?

> I found the issue when an user tries to write a "safe" installer
> script under "DROP before CREATE" coding rule:

> 1. DROP OPERATOR IF EXISTS <<< ... ;
> 2. CREATE OPERATOR <<< (... COMMUTATOR >>>);
> 3. DROP OPERATOR IF EXISTS >>> ... ;
> 4. CREATE OPERATOR >>> (... COMMUTATOR <<<);

> 3 drops catalog-only >>> added at 2, and 4 adds a operator that
> has a different oid from <<<'s commutator. The operator <<<
> becomes broken state in system catalog.

> Anyway, it must be a rare case, and we can just avoid the usage.

Yeah. The above script seems incorrect anyway: if we did clean
up the commutator links fully then step 3 would undo the effect
of step 2. So really you should drop all the operators first
and then start creating new ones.

On the other hand ... the above script pattern would do the right thing
if OperatorUpd() were willing to overwrite existing nonzero values in
the referenced operators' entries. I'm not sure if this is a good idea
though. I think that the reason it doesn't do it now is so that you
don't accidentally damage the links in an existing unrelated operator.
But AFAICS there are no cases where commutator and negator pairs
shouldn't be symmetrical, so simply doing nothing doesn't seem like the
right thing either: if you don't modify the other operator then you're
definitely leaving an inconsistent state in the catalogs. Maybe what we
should do is require the user to own the referenced operator and then
unconditionally force the referenced operator's link to match.

regards, tom lane