Re: [BUGS] base_yylex undefined in src/interface/ecpg/preproc/parser.c
От | Tom Lane |
---|---|
Тема | Re: [BUGS] base_yylex undefined in src/interface/ecpg/preproc/parser.c |
Дата | |
Msg-id | 12637.1481481170@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [BUGS] base_yylex undefined in src/interface/ecpg/preproc/parser.c (Дилян Палаузов<dpa-postgres@aegee.org>) |
Ответы |
Re: [BUGS] base_yylex undefined in src/interface/ecpg/preproc/parser.c
|
Список | pgsql-bugs |
Дилян Палаузов <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 affectssome other names that* various files expect *not* to be prefixed with "base_". Cleaning it up* is not worth the troubleright now.*/ #define yylex base_yylex #define yylval base_yylval Looks like it's time to pay down that technical debt. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: