Re: Possible bug with ALTER LANGUAGE ... OWNER TO ...
От | Erik Jones |
---|---|
Тема | Re: Possible bug with ALTER LANGUAGE ... OWNER TO ... |
Дата | |
Msg-id | 0BBF3E77-F238-45C7-AA0F-51B0422EF9BD@engineyard.com обсуждение исходный текст |
Ответ на | Re: Possible bug with ALTER LANGUAGE ... OWNER TO ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Dec 9, 2008, at 3:50 PM, Tom Lane wrote: > 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? Only if the commands to create the objects being altered also created the underlying functions. I think the distinction should be that if command actually *creates* other objects beyond the "top level" object created with established relationships via pg_depend then that relationship should be followed by appropriate ALTER statements on the originally created objects. Perhaps OWNED BY would be a good add to ALTER FUNCTION statements to couple them to other objects when appropriate and create statements for other objects that create functions will have that be implicit? After all, the only reason those secondary objects are there is for use by the primarily created object. One pre-existing example is sequence created with the SERIAL keyword in CREATE TABLE/ALTER TABLE statements, they're still independent objects that can be ALTERed directly but a subsequent ALTER on the owning table propagates to the sequence. That being said, I'm satisfied now that I know that it isn't something that's already supposed to work. Just saying that it'd be nice :) Erik Jones, Database Administrator Engine Yard Support, Scalability, Reliability 866.518.9273 x 260 Location: US/Pacific IRC: mage2k
В списке pgsql-general по дате отправления: