pgsql: Improve parser's one-extra-token lookahead mechanism.
От | Tom Lane |
---|---|
Тема | pgsql: Improve parser's one-extra-token lookahead mechanism. |
Дата | |
Msg-id | E1YQOMe-0001Od-QY@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Improve parser's one-extra-token lookahead mechanism. There are a couple of places in our grammar that fail to be strict LALR(1), by requiring more than a single token of lookahead to decide what to do. Up to now we've dealt with that by using a filter between the lexer and parser that merges adjacent tokens into one in the places where two tokens of lookahead are necessary. But that creates a number of user-visible anomalies, for instance that you can't name a CTE "ordinality" because "WITH ordinality AS ..." triggers folding of WITH and ORDINALITY into one token. I realized that there's a better way. In this patch, we still do the lookahead basically as before, but we never merge the second token into the first; we replace just the first token by a special lookahead symbol when one of the lookahead pairs is seen. This requires a couple extra productions in the grammar, but it involves fewer special tokens, so that the grammar tables come out a bit smaller than before. The filter logic is no slower than before, perhaps a bit faster. I also fixed the filter logic so that when backing up after a lookahead, the current token's terminator is correctly restored; this eliminates some weird behavior in error message issuance, as is shown by the one change in existing regression test outputs. I believe that this patch entirely eliminates odd behaviors caused by lookahead for WITH. It doesn't really improve the situation for NULLS followed by FIRST/LAST unfortunately: those sequences still act like a reserved word, even though there are cases where they should be seen as two ordinary identifiers, eg "SELECT nulls first FROM ...". I experimented with additional grammar hacks but couldn't find any simple solution for that. Still, this is better than before, and it seems much more likely that we *could* somehow solve the NULLS case on the basis of this filter behavior than the previous one. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/d809fd0008a2e26de463f47b7aba0365264078f3 Modified Files -------------- src/backend/parser/gram.y | 35 ++++++--- src/backend/parser/parser.c | 105 ++++++++++++++----------- src/include/parser/gramparse.h | 2 + src/interfaces/ecpg/preproc/parse.pl | 6 +- src/interfaces/ecpg/preproc/parser.c | 116 ++++++++++++++++------------ src/test/regress/expected/foreign_data.out | 2 +- src/test/regress/expected/with.out | 15 ++++ src/test/regress/sql/with.sql | 5 ++ 8 files changed, 173 insertions(+), 113 deletions(-)
В списке pgsql-committers по дате отправления: