Re: pure parsers and reentrant scanners

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> On 20.12.24 02:07, Tom Lane wrote:
>> I noticed that lapwing is bleating about
>> cubescan.c:1689:5: warning: no previous prototype for 'cube_yyget_column' [-Wmissing-prototypes]
>> cubescan.c:1765:6: warning: no previous prototype for 'cube_yyset_column' [-Wmissing-prototypes]
>> and likewise in segscan.c. lapwing is using flex 2.5.35, so probably
>> this is the same bug worked around in parser/scan.l:

> Ok, we can fix that, but maybe this is also a good moment to think about
> whether that is useful. I could not reproduce the issue with flex
> 2.5.39. I could find no download of flex 2.5.35. The github site only
> offers back to 2.5.39, the sourceforce site back to 2.5.36. lapwing
> says it's Debian 7.0, which went out of support in 2016 and out of
> super-duper-extended support in 2020. It also doesn't have a supported
> OpenSSL version anymore, and IIRC, it has a weird old compiler that
> occasionally gives bogus warnings. I think it's time to stop supporting
> this.

OK, that's fair. I do see lapwing called out a lot in the commit log,
though it's not clear how much of that is about 32-bitness and how
much about old tools. It's surely still valuable to have i386
machines in the buildfarm, but I agree that supporting unobtainable
tool versions is a bit much. Could we get that animal updated to
some newer OS version?

Presumably, we should also rip out the existing yyget_column and
yyset_column kluges in

src/backend/parser/scan.l: extern int core_yyget_column(yyscan_t yyscanner);
src/bin/psql/psqlscanslash.l: extern int slash_yyget_column(yyscan_t yyscanner);
src/bin/pgbench/exprscan.l: extern int expr_yyget_column(yyscan_t yyscanner);
src/fe_utils/psqlscan.l: extern int psql_yyget_column(yyscan_t yyscanner);

regards, tom lane