Re: base_yylex undefined in src/interface/ecpg/preproc/parser.c
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Дилян Палаузов <dpa-postgres@aegee.org>
Cc: pgsql-bugs@postgresql.org
Date: 2016-12-11T18:32:50Z
Lists: pgsql-bugs
=?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <dpa-postgres@aegee.org> writes: > with the newest flex (v2.6.2-19-g6bea32e, which is newer than 2.6.3) I > need this patch to compile postgres: Ugh. > With previous versions of flex the compilation has worked. But I do not > find in the code where is supposed yylex to be renamed to base_yylex > when parser.c is proccessed. pgc.l also does not use %option > prefix=base_yy, which would be the right way to rename yylex (apart from > #define YY_DECL). > What is the purpose to rename yylex to base_yylex? It's mostly for consistency with the backend, where we have multiple bison parsers (and multiple flex lexers) so there's a policy of renaming all of them away from the default name. Since ecpg is a standalone program, we could in principle not bother to rename its parser; but I'd rather keep it in as close sync with the corresponding backend code as possible. The reason for the current hacky approach is explained in pgc.l: /* * Change symbol names as expected by preproc.y. It'd be better to do this * with %option prefix="base_yy", but that affects some other names that * various files expect *not* to be prefixed with "base_". Cleaning it up * is not worth the trouble right now. */ #define yylex base_yylex #define yylval base_yylval Looks like it's time to pay down that technical debt. regards, tom lane
Commits
-
Use "%option prefix" to set API names in ecpg's lexer.
- fb12471ebec1 9.4.11 landed
- 2d48131ed144 9.2.20 landed
- 2bdee07abefe 9.3.16 landed
- 15b3722700ca 9.5.6 landed
- 92fb649837e3 10.0 landed
- 89d1dfa49aaf 9.6.2 landed
-
Build backend/parser/scan.l and interfaces/ecpg/preproc/pgc.l standalone.
- 329361cfa320 9.2.20 landed
- 73ae395d8419 9.3.16 landed
- 7192865bdc48 9.4.11 landed
- 4262c5b1eecc 9.5.6 landed
- 72b1e3a21f05 9.6.0 cited