]> granicus.if.org Git - postgresql/commit
Re-refactor the core scanner's API, in order to get out from under the problem
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 9 Nov 2009 18:38:48 +0000 (18:38 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 9 Nov 2009 18:38:48 +0000 (18:38 +0000)
commit10bcfa189bedaeaa6bfe8d7841ed3b17f23c0df4
tree70b98c6fd252fb828a393d830322f64b37cd5e81
parent2ace38d226246b83e5cc4d8f4063a82a485ddc95
Re-refactor the core scanner's API, in order to get out from under the problem
of different parsers having different YYSTYPE unions that they want to use
with it.  I defined a new union core_YYSTYPE that is just the (very short)
list of semantic values returned by the core scanner.  I had originally
worried that this would require an extra interface layer, but actually we can
have parser.c's base_yylex (formerly filtered_base_yylex) take care of that at
no extra cost.  Names associated with the core scanner are now "core_yy_foo",
with "base_yy_foo" being used in the core Bison parser and the parser.c
interface layer.

This solves the last serious stumbling block to eliminating plpgsql's separate
lexer.  One restriction that will still be present is that plpgsql and the
core will have to agree on the token numbers assigned to tokens that can be
returned by the core lexer.  Since Bison doesn't seem willing to accept
external assignments of those numbers, we'll have to live with decreeing that
core and plpgsql grammars declare these tokens first and in the same order.
src/backend/parser/gram.y
src/backend/parser/parser.c
src/backend/parser/scan.l
src/include/parser/gramparse.h
src/include/parser/scanner.h [new file with mode: 0644]