Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

Поиск
Список
Период
Сортировка
От Roma Sokolov
Тема Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
Дата
Msg-id A136D245-A2D6-4A19-BCC5-F8B19105B05A@gmail.com
обсуждение исходный текст
Ответ на [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator  (Roma Sokolov <sokolov.r.v@gmail.com>)
Ответы Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
Hi,

Tomas, thanks for review and comments!

> I have to admit I find the existing code a bit convoluted, particularly the part that deals with the (commId ==
negId)case. And the patch does not really improve the situation, quite the contrary. 
>
> Perhaps it’s time to get rid of this optimization?

Indeed, code in OperatorUpd is not very easy to read, due to handling this case.
However we can achieve the same results without too much duplication. I have
changed OperatorUpd to perform tuple modification in "lazy" way. Please, check
it out in v4.patch (attached).

> Also, maybe I'm missing something obvious, but it's not immediately obvious to me why we're only checking oprcom and
notoprnegate? I.e. why shouldn’t the code be 

We do not need to check for operOid != op->oprnegate, since we can't create
operator that is negator to itself. Thus, opnergate either present and differs
from operator being deleted, or is InvalidOid. I have added some clarification
in the comment for future readers.


Fixed style issues as well.

Cheers,
Roma


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Следующее
От: Álvaro Hernández Tortosa
Дата:
Сообщение: Re: about google summer of code 2016