Re: Dropping PL language retains support functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dropping PL language retains support functions
Date
Msg-id 29293.1331048311@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dropping PL language retains support functions  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Dropping PL language retains support functions  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.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.

> 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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: elegant and effective way for running jobs inside a database
Next
From: Simon Riggs
Date:
Subject: Re: Checksums, state of play