Re: PlPython - Mailing list pgsql-general

From Tom Lane
Subject Re: PlPython
Date
Msg-id 13235.1056401602@sss.pgh.pa.us
Whole thread Raw
In response to Re: PlPython  (elein <elein@varlena.com>)
Responses Re: [HACKERS] PlPython  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PlPython  (elein <elein@varlena.com>)
List pgsql-general
elein  <elein@varlena.com> writes:
> For 7.4 (which I expect is the patch's target) it might be
> best to make both names point to the same thing with a
> clear release note that says that they are the same thing
> and that plpython[u] is now untrusted.

I don't know any way to actually do that, though.  If we put two entries
in pg_language then functions created in plpython will stay associated
with that entry.  That'd probably be the worst of all possible worlds,
since a person looking at pg_language would quite reasonably assume that
plpython was still trusted and the untrusted plpythonu was just an
addition.  (Especially if he happened to know that such an addition was
planned long ago.)  You could shoot yourself in the foot pretty badly
with such a misunderstanding :-(

The behavior that I think would be most useful would be to automatically
transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION
... LANGUAGE "plpythonu".  Which we could do with an ugly hack in CREATE
FUNCTION (ugly, but no worse than things we've done to index opclass
names, for example).  But it could be too confusing.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Eliminating start error message: "unary operator
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] PlPython