On Mon, Mar 05, 2012 at 11:38:33PM -0500, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > By doing a DROP CASCADE on plpython2, you drop the user functions, but > > not the support functions. > > Well, yeah. The language depends on the support functions, not the > other way around. > > > This certainly looks like a bug. Should I work on a patch? > > It's not a bug, and it's unlikely you can "fix" it in pg_upgrade without > making things worse. > > The long-run plan is that the procedural language and its support > functions are all part of an extension and what you do is drop the > extension. We're not quite there yet. As of 9.1, if you do "create > extension plpython2" to start with, dropping the extension does drop the > support functions too ... but if you use the legacy "create language" > syntax, that doesn't happen, because an extension object isn't created.
Well, if CREATE LANGUAGE created those functions, it seems logical that DROP FUNCTION removes them. Why is that not a bug? I am not saying we have to fix it, but sure seems like a bug to me. Are you saying other objects might rely on those functions? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
