Re: Procedural language permissions and consequences

From: Doug McNaught <doug(at)wireboard(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Procedural language permissions and consequences
Date: 2002-01-16 03:36:57
Message-ID: m3n0zfvuee.fsf@varsoon.denali.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:

> Furthermore, we can conveniently eliminate the problems related to finding
> all the language handlers as shared libraries. Since all languages are
> installed by default we can just link the handlers right into the
> postmaster, for which we don't need shared libraries. That should give a
> great boost to languages that are currently hard to build, i.e., PL/Perl
> and PL/Python. And the build system would become a lot simpler and more
> portable.
>
> Any comments on these points?

Just that I imagine it's quite useful, while hacking on a procedural
language, to be able to restart the postmaster and reload the library,
rather than relinking and reinstalling the postmaster binary. So
keeping the option for PLs in shared libraries is probably a good
idea, though having the "standard" ones compiled in makes some sense.

Wouldn't a postmaster statically linked with libperl.a and libpyhon.a
be pretty big? Would that cause problems?

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-01-16 05:22:13 Re: 7.1 vs. 7.2 on AIX 5L
Previous Message Peter Eisentraut 2002-01-16 03:09:17 Procedural language permissions and consequences