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

From Tom Lane
Subject Re: clearing opfuncid vs. parallel query
Date
Msg-id 6349.1443112450@sss.pgh.pa.us
Whole thread Raw
In response to Re: clearing opfuncid vs. parallel query  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I think allowing an operator's implementation function to change would
> be rather problematic, would it not?  There's no way to know whether the
> semantic changes to stored rules would make sense, not least because the
> person running ALTER OPERATOR wouldn't know (== has no easy way to find
> out) what is being changed in the first place.

> To me, it looks like we should just not allow ALTER OPERATOR SET FUNCTION
> to be implemented at all.

> It's not like changing an operator's implementation is an oft-requested
> feature anyway.

Well, the point is that usually anything you want in this line can be
accomplished by executing CREATE OR REPLACE FUNCTION on the operator's
function.  It's up to you that that doesn't create any interesting
semantic incompatibilities.  That would still be true for an ALTER
OPERATOR SET FUNCTION command: if you break it, you get to keep both
pieces.  But the availability of that alternative really cuts down
on the plausible use-cases for ALTER OPERATOR SET FUNCTION.
        regards, tom lane



pgsql-hackers by date:

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