From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Andrew Bosma <andrew(at)corvus(dot)biomed(dot)brown(dot)edu> |
Subject: | Re: State of PL/Python build |
Date: | 2001-05-15 17:09:14 |
Message-ID: | 10401.989946554@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 could even see people doing this on platforms where they didn't have
to (because a non-PIC libpython or libperl could be included into a
shared library plpython or plperl). It should give a performance
advantage, which might be interesting to heavy users of those PLs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-05-15 17:09:47 | Re: please apply patch for GiST (7.1.1, current cvs) |
Previous Message | Peter Eisentraut | 2001-05-15 17:02:22 | Re: State of PL/Python build |