Re: PlPython

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PlPython
Дата
Msg-id 13235.1056401602@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PlPython  (elein <elein@varlena.com>)
Ответы Re: [HACKERS] PlPython  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PlPython  (elein <elein@varlena.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Eliminating start error message: "unary operator
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] PlPython