=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> I'll do that for PL/Python for now. While on the topic of needless FATAL
> errors, if you try to create a Python 3 function in a session that
> already loaded Python 2, you get a FATAL error with an errhint of
> Start a new session to use a different Pyt
On 28/11/10 05:23, Andrew Dunstan wrote:
>
>
> On 11/27/2010 10:28 PM, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> I noticed that PL/Python uses a simple wrapper around malloc that does
>>> ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
>>> normally do
On 11/27/2010 10:28 PM, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
I noticed that PL/Python uses a simple wrapper around malloc that does
ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
normally do ERROR if we run out of memory?
And while looking at how PL
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> I noticed that PL/Python uses a simple wrapper around malloc that does
> ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
> normally do ERROR if we run out of memory?
> And while looking at how PL/Perl does these things I find that
I noticed that PL/Python uses a simple wrapper around malloc that does
ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
normally do ERROR if we run out of memory?
And while looking at how PL/Perl does these things I find that one
failed malloc (in compile_plperl_function) thr
