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
