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
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 |