Re: [HACKERS] Consistently catch errors from Python _New() functions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] Consistently catch errors from Python _New() functions
Date
Msg-id b5c7b347-e33b-310c-4a2f-b7e0f302674e@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Consistently catch errors from Python _New() functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Consistently catch errors from Python _New() functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Next
From: Sophie Herold
Date:
Subject: Re: to_typemod(type_name) information function