Re: Procedural language permissions and consequences

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Procedural language permissions and consequences
Дата
Msg-id Pine.LNX.4.30.0201161123480.730-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: Procedural language permissions and consequences  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane writes:

> This I do *not* like.  plpgsql is the single thing keeping us honest
> on portability of shlib extensions.

That is not correct.  The regression tests load and use all kinds of other
shared library extensions.

I certainly don't like the notion you suggest that we should create or
keep arbitrary detours in the common usage path just to prove that those
detours still work.  That is what test suites are for, and I'd be happy to
provide more tests if what we currently have doesn't satisfy you
(including a dummy dynamically loaded language handler?).

I could see a build-time option to determine in which way the PL handlers
are linked, but I really don't buy this argument.

> And I do not see it as our problem that perl and python make life
> unnecessarily difficult for those who would include them as libraries.

In a sense it is our problem, because we are providing features that are
based on interfaces that don't officially exist, and we are making life
more difficult for users that way.  Years of Apache/mod_perl didn't
convince anybody to provide a shared libperl, so what makes you think
someone is going to start on our say-so?

-- 
Peter Eisentraut   peter_e@gmx.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Turbo Fredriksson
Дата:
Сообщение: Re: RServ replication
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Procedural language permissions and consequences