Re: Making plpython 2 and 3 coexist a bit better
От | Jim Nasby |
---|---|
Тема | Re: Making plpython 2 and 3 coexist a bit better |
Дата | |
Msg-id | 5693F958.2080708@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Making plpython 2 and 3 coexist a bit better (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Making plpython 2 and 3 coexist a bit better
|
Список | 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 по дате отправления: