operator dependency of commutator and negator, redux

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: operator dependency of commutator and negator, redux
Date: 2012-12-20 00:51:19
Message-ID: 26305.1355964679@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-20 01:29:16 Re: strange OOM errors with EXECUTE in PL/pgSQL
Previous Message Robert Haas 2012-12-20 00:43:44 Re: Set visibility map bit after HOT prune