From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Making plpython 2 and 3 coexist a bit better |
Date: | 2016-01-11 18:50:00 |
Message-ID: | 5693F958.2080708@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Pedersen | 2016-01-11 18:51:03 | Re: Speedup twophase transactions |
Previous Message | Pavel Stehule | 2016-01-11 18:46:05 | Re: proposal: PL/Pythonu - function ereport |