Re: Procedural language permissions and consequences

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Procedural language permissions and consequences
Date: 2002-01-16 16:41:39
Message-ID: Pine.LNX.4.30.0201161123480.730-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmx(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-01-16 17:10:52 Re: tuptoaster.c must *not* use SnapshotAny
Previous Message Peter Eisentraut 2002-01-16 16:23:42 Re: Procedural language permissions and consequences