From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: clearing opfuncid vs. parallel query |
Date: | 2015-09-24 16:04:14 |
Message-ID: | 20150924160414.GD295765@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> 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.
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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-24 16:34:10 | Re: clearing opfuncid vs. parallel query |
Previous Message | Robert Haas | 2015-09-24 16:03:14 | Re: clearing opfuncid vs. parallel query |