Re: clearing opfuncid vs. parallel query - Mailing list pgsql-hackers

From Robert Haas
Subject Re: clearing opfuncid vs. parallel query
Date
Msg-id CA+TgmoYp3j5cuLRtmN0PiKYJUkr_vVEg4_NC_4pcWiJ1Gc8WDA@mail.gmail.com
Whole thread Raw
In response to Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: clearing opfuncid vs. parallel query  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Sep 24, 2015 at 11:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2015-09-23 17:29:50 -0400, Robert Haas wrote:
>>> Well, I can't vouch for what any human being on earth has thought
>>> about over a twenty-year period.  It's not intrinsically unreasonable
>>> in my mind to want to alter an operator to point at a different
>>> procedure.
>
>> Wouldn't we use plan invalidation to deal with that anyway?
>
> Plan invalidation wouldn't help, because the obsolete data exists
> on-disk in stored rules.  You'd have to run through the pg_rewrite
> entries and update them.
>
> To my mind though, the lack of an ALTER OPERATOR SET FUNCTION command
> is on par with our very limited ability to alter the contents of
> an operator class.  In principle it would be nice, but the practical
> value is so small that it's not surprising it hasn't been done ---
> and we shouldn't continue to hold the door open for a simple way of
> implementing it when there are significant costs to doing so.

Also, it's not like this change couldn't be UN-done at a future point.
I mean, Tom didn't like the flag I added aesthetically, but if we
needed it, we could have it.  Or we could engineer something else.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: clearing opfuncid vs. parallel query
Next
From: Alvaro Herrera
Date:
Subject: Re: clearing opfuncid vs. parallel query