Tom Lane 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 e
Andrew Dunstan 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-
On 03/05/2011 12:17 PM, Tom Lane wrote:
Dimitri Fontaine writes:
Tom Lane 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 simples
Dimitri Fontaine writes:
> Tom Lane 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 tha
Tom Lane 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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 t
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, si
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
