Re: Making plpython 2 and 3 coexist a bit better - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Making plpython 2 and 3 coexist a bit better
Date
Msg-id 5693F958.2080708@BlueTreble.com
Whole thread Raw
In response to Re: Making plpython 2 and 3 coexist a bit better  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Making plpython 2 and 3 coexist a bit better  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 type seem unpreventable
> unless we stick with the immediate-FATAL-error approach.

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 process for executing functions, maybe we 
could do something like that? If we treated 2 and 3 as different 
languages you could actually use both at the same time in a single 
backend. The only thing that's not clear to me is how you'd be able to 
re-enter the process during recursive/nested calls.

Obviously this is a lot more work than what you're proposing though. :(
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: PL/Pythonu - function ereport
Next
From: Jesper Pedersen
Date:
Subject: Re: Speedup twophase transactions