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 17:41:52
Message-ID: 10336.1458754912@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:
> On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

> So what? We've never guaranteed that things are going to work if you
> start by corrupting the catalogs, and I wouldn't pick this as a place
> to start.

I would not be worried except that it breaks a case that used to work,
as your test below demonstrates.

>> 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.

> I tried this, but it did not seem to work.

Odd. If you post the revised patch, I'll try to chase down what's wrong.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladimir Sitnikov 2016-03-23 17:46:05 Re: NOT EXIST for PREPARE
Previous Message Tom Lane 2016-03-23 17:37:28 Re: PostgreSQL 9.6 behavior change with set returning (funct).*