operator dependency of commutator and negator, redux - Mailing list pgsql-hackers

From Tom Lane
Subject operator dependency of commutator and negator, redux
Date
Msg-id 26305.1355964679@sss.pgh.pa.us
Whole thread Raw
Responses Re: operator dependency of commutator and negator, redux  (Brendan Jurd <direvus@gmail.com>)
List pgsql-hackers
Bug #7758 seems to be a rediscovery of the behavior that Itagaki-san
complained of a couple years ago:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg02035.php

While reconsidering the various not-too-satisfactory fixes we thought of
back then, I had a sudden thought.  Instead of having a COMMUTATOR or
NEGATOR forward reference create a "shell" operator and link to it,
why not simply *ignore* such references?  Then when the second operator
is defined, go ahead and fill in both links?

The only case where this could result in an unsatisfactory outcome is
if the second operator's CREATE command fails to include the converse
COMMUTATOR or NEGATOR reference ... but that doesn't work very nicely
today anyway, as you end up with a unidirectional reference, hardly a
desirable state of affairs.

Not only does this solve the problem complained of, but it allows for
much stronger error checking, as there is no longer any need to allow
inconsistent catalog states even transiently.  We could start treating
commutator/negator references as true dependencies, permanently
preventing dangling references.  We could probably even get rid of the
notion of shell operators altogether.

Thoughts?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Set visibility map bit after HOT prune
Next
From: Tom Lane
Date:
Subject: Re: strange OOM errors with EXECUTE in PL/pgSQL