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 |
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 |