On 11/14/18, Tom Lane <t...@sss.pgh.pa.us> wrote: > Looks like good stuff, pushed with a small additional amount of work.
Thanks. >> -Does ECPG still need its own functions for mm_alloc() and >> mm_strdup(), if we have equivalents in src/common? > > The error handling isn't the same, so I don't think we can just replace > them with the src/common functions. It is, however, potentially worth > our trouble to fix things so that within pgc.l, palloc() and pstrdup() > are macros for mm_alloc/mm_strdup, thereby further reducing the diffs > to the core lexer. > > I'd be pretty tempted to also change all the hard references to > base_yylval to go through a pointer variable, so that diffs like > this go away: > > - yylval->str = pstrdup(yytext); > + base_yylval.str = mm_strdup(yytext); > > I believe that that'd result in more compact code, too --- on most > machines, references to global variables are more expensive in > code bytes than indirecting through a local pointer variable. I'll look into that as time permits. On 11/14/18, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> On 2018-Nov-13, Tom Lane wrote: >>> More generally, I wonder if it'd be practical to make pgc.l backup-free >>> altogether. I'm not sure that the resulting gain in lexing speed would >>> really be of interest to anyone, > >> Maybe time to compile the ecpg test cases during "make check-world"? > > I'm dubious that the lexer is a significant part of that, though I could > be wrong ... If it were, it'd be much easier to try a Flex flag other than the default, most compact representation, something like -Cfe. That'd be a prerequisite for no-backtracking to matter anyway. That's easy enough to test, so I'll volunteer to do that sometime. -John Naylor
