On Dec 9, 2008, at 3:50 PM, Tom Lane wrote:
Alvaro Herrera <alvhe...@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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
