Re: Making plpython 2 and 3 coexist a bit better

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> 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 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.

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.

> Obviously this is a lot more work than what you're proposing though. :(

Yeah. I think what I'm suggesting is a back-patchable fix, which that
certainly wouldn't be.

I realized that the patch I put up before would do the Wrong Thing if
an updated library were loaded followed by a not-updated library for
the other python version. Ideally that couldn't happen, but considering
that the two plpythons are likely to get packaged in separate subpackages
(certainly Red Hat does things that way), it's not too hard to envision
cases where it would. So the attached update corrects that and fixes the
docs too. We can lose the whole test in HEAD, but I think it's necessary
in the back branches.

The question of whether to do ERROR or FATAL remains open. I'm not sure
I have a strong preference either way.

regards, tom lane