Re: [HACKERS] Consistently catch errors from Python _New() functions

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Consistently catch errors from Python _New() functions
Date: 2017-11-18 16:33:07
Message-ID: b5c7b347-e33b-310c-4a2f-b7e0f302674e@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/17/17 12:16, Tom Lane wrote:
> I'm confused by the places that change PLy_elog calls to pass NULL:
>
> - PLy_elog(ERROR, "could not create globals");
> + PLy_elog(ERROR, NULL);
>
> How is that an improvement? Otherwise it looks reasonable.

If we pass NULL, then the current Python exception becomes the primary
error, so you'd end up with an "out of memory" error of some kind with a
stack trace, which seems useful.

The previous coding style invented a bespoke error message for each of
these rare out of memory scenarios, which seems wasteful. We don't
create "out of memory while creating some internal list you've never
heard of" errors elsewhere either.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sophie Herold 2017-11-18 16:58:16 Re: to_typemod(type_name) information function
Previous Message Peter Eisentraut 2017-11-18 15:56:23 Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256