Re: Possible bug with ALTER LANGUAGE ... OWNER TO ...
| От | Tom Lane |
|---|---|
| Тема | Re: Possible bug with ALTER LANGUAGE ... OWNER TO ... |
| Дата | |
| Msg-id | 23287.1228866631@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Possible bug with ALTER LANGUAGE ... OWNER TO ... (Alvaro Herrera <alvherre@commandprompt.com>) |
| Ответы |
Re: Possible bug with ALTER LANGUAGE ... OWNER TO ...
|
| Список | pgsql-general |
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Well, since CREATE LANGUAGE creates the functions internally, it does
> make a certain amount of sense that the functions are also handled
> internally when you do stuff to the language.
It *might* create the functions internally, or it might not. Admittedly
the present behavior is somewhat skewed by historical compatibility
considerations, but as long as the functions are independently creatable
objects I don't think it makes sense to have ALTER LANGUAGE messing with
them.
We'd be heading down a very slippery slope if we did that, too ---
should ALTER AGGREGATE touch the underlying functions? How about ALTER
CONVERSION propagating to the underlying function? Or ALTER TYPE to its
underlying I/O functions? Or ALTER DOMAIN to the underlying type? Etc.
If we did change this, how do we not break pg_dump's ability to
replicate a situation where tbe ownerships had been different?
regards, tom lane
В списке pgsql-general по дате отправления: