Re: PlPython

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: elein(at)varlena(dot)com
Cc: Kevin Jacobs <jacobs(at)penguin(dot)theopalgroup(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: PlPython
Date: 2003-06-23 20:53:22
Message-ID: 13235.1056401602@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

elein <elein(at)varlena(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2003-06-23 21:04:20 Re: [HACKERS] PlPython
Previous Message Tom Lane 2003-06-23 20:45:51 Re: Eliminating start error message: "unary operator

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-06-23 21:04:20 Re: [HACKERS] PlPython
Previous Message Michael Brusser 2003-06-23 20:45:10 Core dump on HP