From: | Mark Hollomon <mhh(at)mindspring(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | static link of plpython/plperl - was Re: State of PL/Python build |
Date: | 2001-05-16 20:35:33 |
Message-ID: | 01051616353301.01007@jupiter.hollomon.fam |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tuesday 15 May 2001 13:09, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Tom Lane writes:
> >> I wonder whether people would like an option to statically link
> >> libperl.a and/or libpython.a into the Postgres backend proper? That
> >> would allow plperl/plpython to be used on platforms where this is an
> >> issue, without having to make a nonstandard build of perl/python.
> >
> > Not unless you also link in plperl/plpython itself or mess with
> > -whole-archive type linker flags.
>
> The former is what I had in mind.
>
> Yes, it's ugly and it bloats the binary, but people would presumably
> only do this if they intended to use the language. So the bloat is
> somewhat illusory. And it's less ugly than having to build a
> nonstandard install of python or perl.
>
I'm not sure it is any uglier than including the (to me) useless geometry
datatypes.
I would be happy to help get this working with plperl.
Another interesting idea is to allow the postmaster to 'preload' some of the
libraries. This would help cut down the startup cost of a new backend that
needed a widely used language.
--
Mark Hollomon
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2001-05-16 20:50:42 | Upgrade issue (again). |
Previous Message | Jan Wieck | 2001-05-16 19:55:52 | Re: inserts on a transaction blocking other inserts |