Re: [HACKERS] Extensions vs. shared procedural language handler functions
Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions vs. shared procedural language handler functions
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@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 text AS 'return zarkon' LANGUAGE plpythonu; ! ERROR: could not load library c:/mingw/msys/1.0/home/pgrunner/bf/root/HEAD/inst/lib/postgresql/plpython.dll: Invalid access 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions vs. shared procedural language handler functions
On 03/05/2011 12:17 PM, Tom Lane wrote: Dimitri Fontainedimi...@2ndquadrant.fr writes: Tom Lanet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions vs. shared procedural language handler functions
Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions vs. shared procedural language handler functions
Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions vs. shared procedural language handler functions
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extensions vs. shared procedural language handler functions
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
