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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Roma Sokolov <sokolov(dot)r(dot)v(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Женя Зайцев <zevlg(at)yandex(dot)ru>
Subject: Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
Date: 2016-03-23 16:27:58
Message-ID: 3531.1458750478@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I did not find this version very clear. It wasn't consistent about
> using ObjectIdGetDatum() where needed, but the bigger problem was that
> I found the logic unnecessarily convoluted. I rewrote it - I believe
> more straightforwardly - as attached. How does this look?

I'd suggest that we save some code by always doing separate updates for
the commutator and negator entries. We can handle the corner case where
they're the same by doing a CommandCounterIncrement between the updates,
instead of having convoluted and probably-never-yet-tested logic.

I'm also a bit dubious of the assumption in RemoveOperatorById that an
operator can't be its own negator. Yeah, that should not be the case,
but if it is the case the deletion will fail outright.

We could resolve both of these issues by changing the semantics of
OprUpdate so that it unconditionally does a CommandCounterIncrement
after each update that it performs. IMO that would be a lot simpler
and more bulletproof; it'd allow removal of a lot of these
overly-tightly-reasoned cases.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-23 16:53:22 Re: Postgres_fdw join pushdown - getting server crash in left outer join of three table
Previous Message David G. Johnston 2016-03-23 16:19:02 Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)