Re: OWNER TO on all objects
От | Tom Lane |
---|---|
Тема | Re: OWNER TO on all objects |
Дата | |
Msg-id | 3442.1087324172@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: OWNER TO on all objects (Peter Eisentraut <peter_e@gmx.net>) |
Список | 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 по дате отправления: