Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> That might change the precedence of the operator
>>
>> So I don't think this objection has a lot of weight.
> IIRC, it was the objection that you put forth when I last attempted to
> do it...
Was it? I vaguely remember objecting to something on the basis of
possible precedence changes, but I don't recall it being RENAME
OPERATOR.
> The question is perhaps not so much whether we can get away
> with it, it's whether the behavior is reasonable and consistent for
> users that don't know implementation details.
Agreed. Probably the main point here is the inconsistency in behavior
for stored rules and constraint/default expressions (which would track
the operator rename and would stay parenthesized correctly), versus
stored function source code (which would not). I don't think it would
surprise anyone that the query texts embedded in their app code don't
magically update ;-) but for the stuff that's "all stored in the
database" they might expect consistency.
On the other hand, the same inconsistency already exists for table and
column names, and I've not heard great squawks about it. So I withdraw
any previous objection I might have made to RENAME OPERATOR. It's not
obvious that it's more dangerous than any other rename.
regards, tom lane