On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote:
> Commit 803716013dc1350f installed a safeguard against loading plpython2
> and plpython3 at the same time, stating
>
> + It is not allowed to use PL/Python based on Python 2 and PL/Python
> + based on Python 3 in the same session,
Bruce Momjian writes:
> On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote:
>> But it gets worse: a report today in pgsql-general points out that
>> even if you have the two languages in use *in different databases*,
>> pg_upgrade will fail, because pg_upgrade rather
On Mon, Jan 18, 2016 at 01:10:05PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote:
> >> But it gets worse: a report today in pgsql-general points out that
> >> even if you have the two languages in use *in different
I wrote:
> In further experimentation, I found out that even with this patch in
> place, the plpython transform extensions still present a dump/reload
> hazard:
> ...
> But I wonder why we couldn't make it do
> LOAD 'plpython3';
I've verified that the attached additional patch makes everything
Commit 803716013dc1350f installed a safeguard against loading plpython2
and plpython3 at the same time, stating
+ It is not allowed to use PL/Python based on Python 2 and PL/Python
+ based on Python 3 in the same session, because the symbols in the
+ dynamic modules would clash, which could
On 1/11/16 11:51 AM, Tom Lane wrote:
We could ameliorate the first of these cases by putting the can't-run-
with-two-pythons error back up to FATAL rather than ERROR, but I'm not
sure that that would be a net improvement --- FATAL errors aren't very
friendly. In any case errors of the second
I wrote:
> I think we might be able to improve this if we don't do the check in
> plpython's _PG_init(), but delay it until we have a need to call into
> libpython; which we could skip doing at _PG_init() time, at the cost
> of perhaps one more flag check per plpython function call to see if
>
Jim Nasby writes:
> Something that's always concerned me about functions in other languages
> is that any kind of snafu in the function/language can hose the backend,
> which you may or may not detect. I've used other databases that (by
> default) spin up a separate
On 1/11/16 1:00 PM, Tom Lane wrote:
There's at least one PL/Java implementation that does that. The
interprocess communication overhead is pretty awful, IIRC. Don't know
what they do about nested calls.
You'd think that pipes wouldn't be that much overhead...
>Obviously this is a lot more
Jim Nasby writes:
> On 1/11/16 1:00 PM, Tom Lane wrote:
>> The question of whether to do ERROR or FATAL remains open. I'm not sure
>> I have a strong preference either way.
> If they both get loaded is there risk of bad data happening? Personally,
> I'll take a
10 matches
Mail list logo