Re: pure parsers and reentrant scanners
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Andreas Karlsson <andreas@proxel.se>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-18T17:43:31Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Return yyparse() result not via global variable
- 473a575e0597 18.0 landed
-
Remove flex version checks
- 0869ea43e9c2 18.0 landed
-
Drop warning-free support for Flex 2.5.35
- 6fdd5d956343 18.0 landed
-
plpgsql: pure parser and reentrant scanner
- 7b27f5fd36cb 18.0 landed
-
flex code modernization: Replace YY_EXTRA_TYPE define with flex option
- b1ef48980ddd 18.0 landed
-
guc: reentrant scanner
- d663f150b5ed 18.0 landed
-
jsonpath scanner: reentrant scanner
- 2a7425d7eef9 18.0 landed
-
syncrep parser: pure parser and reentrant scanner
- db6856c9913f 18.0 landed
-
replication parser: pure parser and reentrant scanner
- e4a8fb8fefb9 18.0 landed
-
bootstrap: pure parser and reentrant scanner
- 3e4bacb17100 18.0 landed
-
Small whitespace improvement
- 399d0f1e11b5 18.0 landed
-
Prevent redeclaration of typedef yyscan_t
- 382092a0cd2c 18.0 landed
-
seg: pure parser and reentrant scanner
- 1f0de66ea2a5 18.0 landed
-
cube: pure parser and reentrant scanner
- 802fe923e3cd 18.0 landed
Peter Eisentraut <peter@eisentraut.org> writes: > I started committing the cube and seg pieces. There were a couple of > complaints from the buildfarm, like > segscan.c:348:15: error: redefinition of typedef 'yyscan_t' is a C11 > feature [-Werror,-Wtypedef-redefinition] > typedef void* yyscan_t; > ... > (Also, we should probably figure out a way to get these warnings before > things hit the buildfarm.) Interestingly, while sifaka shows that, its sibling indri doesn't. Same compiler, same CFLAGS. I think the relevant difference must be that sifaka is using a much older Bison version (the Apple-supplied 2.3, versus MacPorts' up-to-the-minute version). I think that sort of thing is exactly why we have the buildfarm. It would not be reasonable to expect CI to cover that many cases. Trying to do so would just make CI slow enough that we'd start looking for a new test phase to put in front of it. regards, tom lane