Thread: Extensions vs. shared procedural language handler functions
So while hacking away at the PLs-as-extension changes I ran across an
unforeseen complication. plperl and plpython use the same C function
entry points for both their trusted and untrusted variants. This is
problematic for making them into extensions, since we need the two
language variants to be different extensions (else you could not install
just one of them) and the extensions can't both own the same handler
function.
I can imagine that someplace down the road we might want to allow
multiple extensions to own the same SQL object; I know that RPMs can
share ownership of files, for comparison. But today is not that day.
The only easy fix I can see at the moment is to arbitrarily create two
pg_proc entries --- they can both point at the same C function, but
there need to be two of 'em.
Anyone have a different answer?
regards, tom lane
On 05/03/11 01:58, Tom Lane wrote: > So while hacking away at the PLs-as-extension changes I ran across an > unforeseen complication. plperl and plpython use the same C function > entry points for both their trusted and untrusted variants. This is > problematic for making them into extensions, since we need the two > language variants to be different extensions (else you could not install > just one of them) and the extensions can't both own the same handler > function. ITYM plperl only, because plpython does not have a trusted variant. But there might be another obstacle here: plpython comes in two variants: plpython2u and plpython3u, and which one is built depends on the compile time configuration. Not sure how that plays with extensions... Cheers, Jan
Jan Urbański <wulczer@wulczer.org> writes:
> ITYM plperl only, because plpython does not have a trusted variant. But
> there might be another obstacle here: plpython comes in two variants:
> plpython2u and plpython3u, and which one is built depends on the compile
> time configuration. Not sure how that plays with extensions...
Sorry, you're right, that issue is actually plpythonu and plpython2u
sharing the same handler. It's basically the same problem though.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > I can imagine that someplace down the road we might want to allow > multiple extensions to own the same SQL object; I know that RPMs can > share ownership of files, for comparison. But today is not that day. […] > Anyone have a different answer? What could be done is to have a common extension that installs the functions, then both plperl and plperlu would require the common bits. That's only practical when we have automatic dependency resolution at install and remove times (it should not be hard to do, but well). So for 9.1, I think you took the simplest path available. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> The only easy fix I can see at the moment is to arbitrarily create two
>> pg_proc entries --- they can both point at the same C function, but
>> there need to be two of 'em.
> So for 9.1, I think you took the simplest path available.
It's never that easy :-(. I've been trying to figure out why frogmouth
(Windows/cygwin buildfarm member) suddenly started failing:
CREATE EXTENSION plpython2u; -- really stupid function just to get the module loaded CREATE FUNCTION stupid() RETURNS
textAS 'return "zarkon"' LANGUAGE plpythonu;
! ERROR: could not load library "c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/inst/lib/postgresql/plpython.dll":
Invalidaccess to memory location.
+ select stupid();
+ ERROR: function stupid() does not exist
and it just hit me what must be going on. plpython's makefile tries to
symlink plpython.dll to plpython2.dll, but that trick evidently
doesn't work on Windows: the system doesn't understand they're the same
library and so trying to load both of them at once fails as above.
The next question is how come this regression test ever worked on that
platform. The reason is that up till my changes for $SUBJECT, when you
issued "CREATE LANGUAGE plpython2u" in a database that already had
plpythonu installed, CREATE LANGUAGE found C functions of the expected
names already present and so it didn't create new ones. This meant that
only plpython.dll ever got loaded, not plpython2.dll, despite what the
pg_pltemplate entry alleges about the shlib name for the latter.
IMO this is all pretty Rube Goldbergian and it's amazing it didn't fail
on more platforms. What I propose to do about it is get rid of the
plpython.dll symlink and just have the pg_pltemplate entry for plpythonu
reference the plpython2 shlib. People who want to switch the referent
for plpythonu to be Python3 will have an extra thing to do, but I
haven't heard of very many people doing that anyway.
regards, tom lane
On 03/05/2011 12:17 PM, Tom Lane wrote: > Dimitri Fontaine<dimitri@2ndQuadrant.fr> writes: >> Tom Lane<tgl@sss.pgh.pa.us> writes: >>> The only easy fix I can see at the moment is to arbitrarily create two >>> pg_proc entries --- they can both point at the same C function, but >>> there need to be two of 'em. >> So for 9.1, I think you took the simplest path available. > It's never that easy :-(. I've been trying to figure out why frogmouth > (Windows/cygwin buildfarm member) suddenly started failing: > It's mingw, not cygwin (brolga is the cygwin animal, and it doesn't build with python.) But good catch on the problem. FYI, I'm working on the MSVC issues. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> FYI, I'm working on the MSVC issues.
Ah, great. I was just about to start hacking something together, but
it'd be better for somebody to do it who can test it before committing...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > The next question is how come this regression test ever worked on that > platform. The reason is that up till my changes for $SUBJECT, when you > issued "CREATE LANGUAGE plpython2u" in a database that already had > plpythonu installed, CREATE LANGUAGE found C functions of the expected > names already present and so it didn't create new ones. This meant that > only plpython.dll ever got loaded, not plpython2.dll, despite what the > pg_pltemplate entry alleges about the shlib name for the latter. Well if we would have a plpython_wrapper extension that loads the common functions and the shared object, then a plpythonu and a plpython2u that depends on the plpython_wrapper extension, would it solve the problem? Instead of an ERROR when an extension you require isn't installed, the code would have to recurse into installing it. That means maintaining a stack of current extension being loaded, I guess. Also, for external PLs it would allow people to distribute a couple of extensions each time. The wrapper one that you have to install as a superuser, possibly in template1, and the PL one that you can install as the database owner. It could be a big enough deal in colo environments. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support