Re: clearing opfuncid vs. parallel query

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: clearing opfuncid vs. parallel query
Дата
Msg-id 6349.1443112450@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: clearing opfuncid vs. parallel query  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: clearing opfuncid vs. parallel query
Следующее
От: Tom Lane
Дата:
Сообщение: Re: clearing opfuncid vs. parallel query