Re: OWNER TO on all objects - Mailing list pgsql-hackers

From Tom Lane
Subject Re: OWNER TO on all objects
Date
Msg-id 3442.1087324172@sss.pgh.pa.us
Whole thread Raw
In response to Re: OWNER TO on all objects  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "V i s h a l Kashyap @ [Sai Hertz And Control Systems]"
Date:
Subject: Re: pg_restore recovery from error.
Next
From: Tom Lane
Date:
Subject: Re: #postgresql report