Re: pure parsers and reentrant scanners

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: pgbuildfarm(at)rjuju(dot)net, Andreas Karlsson <andreas(at)proxel(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pure parsers and reentrant scanners
Date: 2025-01-09 07:55:29
Message-ID: d5eba919-3827-452a-9624-91c7b7043760@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20.12.24 16:23, Tom Lane wrote:
>> 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);

All my flex-related patches are in now.

Here is a patch that removes the workarounds for compiler warnings with
flex 2.5.35. This ended up being a whole lot, including the whole
fix-old-flex-code.pl script.

The second patch contemplates raising the minimum required flex version,
but what to?

The most recent incrementing was exactly because 2.5.35 was the oldest
in the buildfarm. The previous incrementings were apparently because
certain features were required or some bugs had to be avoided.

Options:

- Leave at 2.5.35 as long as it's present in the buildfarm.

- Set to 2.5.36 because it's the oldest that compiles without warnings.
Also, the oldest you can still download from the flex sourceforge site.

- Set to 2.5.37 because that's the next oldest in the buildfarm (for
CentOS/RHEL 7, so it will stay around for a while).

- Set to 2.5.34 because that's the oldest we actually require as of
commit b1ef48980dd.

- Remove version check, because these are all so old that no one cares
anymore.

Attachment Content-Type Size
0001-Drop-warning-free-support-for-flex-2.5.35.patch text/plain 11.2 KB
0002-Raise-minimum-flex-version-to-2.5.37.patch text/plain 5.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2025-01-09 07:59:52 Re: Make pg_stat_io view count IOs as bytes instead of blocks
Previous Message Michael Paquier 2025-01-09 07:55:18 Re: [PATCH] Add get_bytes() and set_bytes() functions