Re: Dropping PL language retains support functions

On Tue, Mar 06, 2012 at 10:38:31AM -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Mon, Mar 05, 2012 at 11:38:33PM -0500, Tom Lane wrote:
> >> Well, yeah. The language depends on the support functions, not the
> >> other way around.
>
> > Well, if CREATE LANGUAGE created those functions, it seems logical that
> > DROP FUNCTION removes them. Why is that not a bug?
>
> You can call it a bug all you want, but changing the way those
> dependencies work is not a good idea. As I said, the right path forward
> is to work towards putting the PL and its support functions into an
> extension, and that change doesn't seem like a "bug fix" so much as a
> fundamental revision of how PLs work.

I understand.

> > Are you saying other
> > objects might rely on those functions?
>
> IIRC we have cases where multiple PLs share the same support functions;
> at least, the CREATE LANGUAGE code is written with the assumption that
> that's okay. Perhaps we'd have to stop doing that in order to let them
> be treated as independent extensions. It needs some thought.

Good point on sharing those functions.

> To my mind this is all bound up with getting rid of pg_pltemplate,
> which was last discussed in this thread:
> http://archives.postgresql.org/pgsql-hackers/2011-08/msg01045.php
> We don't seem to quite have consensus on how to proceed forward.

OK. At least I understand what is happening, but it certainly surprised
me. We need to pass on the idea that users have to manually delete
those functions if they are going from plpython2 to plpython3 with
pg_upgrade. I think users have been doing it in the past by not
switching from plpython2 to plpython3 during the upgrade, but the
one-click installer change makes that necessary.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +