Re: SQL/JSON: functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL/JSON: functions
Date
Msg-id 2636477.1647997650@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL/JSON: functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL/JSON: functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> There's also
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26
>> that started failing with
>> ../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc
>> test1.pgc:12: ERROR: syntax error at or near "int"
>> with this commit.

> Yeah, I was just scratching my head about that.

I have a possibly-far-fetched theory: the ecpg grammar builder has
certainly never been validated against a backend grammar that
contains unused rules or unused nonterminals.  Maybe it generates
a subtly incorrect .y file in such cases, and on this particular
platform that results in bad code generated by bison, and ensuing
bogus syntax errors.

The lack of other failures weakens this theory.  Notably, I failed
to duplicate the problem on florican's host, which has the same
nominal bison version 3.7.6.  But it wouldn't surprise me a bit
to find that OpenBSD is carrying some private patches for their
build, so maybe that matters?

In any case, I think it's a bit pointless to chase these issues
with respect to this intermediate state of the JSON patch.
Let's merge in the next step, get to a state that does not
generate build warnings, and see what happens then.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Probable CF bot degradation
Next
From: Michael Paquier
Date:
Subject: Re: Allow file inclusion in pg_hba and pg_ident files