Re: PL/R regression on windows, but not linux with master.

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

In response to

Responses

Browse pgsql-hackers by date

  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