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 по дате отправления: