operator dependency of commutator and negator, redux

Поиск
Список
Период
Сортировка
От Tom Lane
Тема operator dependency of commutator and negator, redux
Дата
Msg-id 26305.1355964679@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: operator dependency of commutator and negator, redux
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Set visibility map bit after HOT prune
Следующее
От: Tom Lane
Дата:
Сообщение: Re: strange OOM errors with EXECUTE in PL/pgSQL