From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Dave Cramer <davecramer(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PL/R regression on windows, but not linux with master. |
Date: | 2021-04-11 15:34:02 |
Message-ID: | 2672048.1618155242@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joe Conway <mail(at)joeconway(dot)com> writes:
> On 4/11/21 10:13 AM, Tom Lane wrote:
>> Indeed. elog.h already provides a "PGERROR" macro to use for restoring
>> the value of ERROR. We have not heard of a need to do anything special
>> for WARNING though --- maybe that's R-specific?
> R also defines WARNING in its headers.
Ah.
> Would an equivalent "PGWARNING" be something we are open to adding and
> back-patching?
It's not real obvious how pl/r could solve this in a reliable way
otherwise, so adding that would be OK with me, but I wonder whether
back-patching is going to help you any. You'd still need to compile
against older headers I should think. So I'd suggest
(1) add PGWARNING in HEAD only
(2) in pl/r, do something like
#ifndef PGWARNING
#define PGWARNING 19
#endif
which should be safe since it's that in all previous supported
versions.
Also, I notice that elog.h is wrapping PGERROR in #ifdef WIN32,
which might be an overly constricted view of when it's helpful.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-04-11 15:47:16 | Re: PANIC: wrong buffer passed to visibilitymap_clear |
Previous Message | Tom Lane | 2021-04-11 15:14:07 | Re: psql - add SHOW_ALL_RESULTS option |