Re: Procedural language permissions and consequences - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Procedural language permissions and consequences
Date
Msg-id Pine.LNX.4.30.0201161123480.730-100000@peter.localdomain
Whole thread Raw
In response to Re: Procedural language permissions and consequences  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Turbo Fredriksson
Date:
Subject: Re: RServ replication
Next
From: Peter Eisentraut
Date:
Subject: Re: Procedural language permissions and consequences