Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

parser

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Tom Lane authored
    Such cases should work, but the grammar failed to accept them because of
    our ancient precedence hacks to convince bison that extra parentheses
    around a sub-SELECT in an expression are unambiguous.  (Formally, they
    *are* ambiguous, but we don't especially care whether they're treated as
    part of the sub-SELECT or part of the expression.  Bison cares, though.)
    Fix by adding a redundant-looking production for this case.
    
    This is a fine example of why fixing shift/reduce conflicts via
    precedence declarations is more dangerous than it looks: you can easily
    cause the parser to reject cases that should work.
    
    This has been wrong since commit 3db4056e
    or maybe before, and apparently some people have been working around it
    by inserting no-op casts.  That method introduces a dump/reload hazard,
    as illustrated in bug #7838 from Jan Mate.  Hence, back-patch to all
    active branches.
    e7105c5f
    History
    src/backend/parser/README
    
    Parser
    ======
    
    This directory does more than tokenize and parse SQL queries.  It also
    creates Query structures for the various complex queries that are passed
    to the optimizer and then executor.
    
    parser.c	things start here
    scan.l		break query into tokens
    scansup.c	handle escapes in input strings
    kwlookup.c	turn keywords into specific tokens
    keywords.c	table of standard keywords (passed to kwlookup.c)
    gram.y		parse the tokens and produce a "raw" parse tree
    analyze.c	top level of parse analysis for optimizable queries
    parse_agg.c	handle aggregates, like SUM(col1),  AVG(col2), ...
    parse_clause.c	handle clauses like WHERE, ORDER BY, GROUP BY, ...
    parse_coerce.c	handle coercing expressions to different data types
    parse_collate.c	assign collation information in completed expressions
    parse_cte.c	handle Common Table Expressions (WITH clauses)
    parse_expr.c	handle expressions like col, col + 3, x = 3 or x = 4
    parse_func.c	handle functions, table.column and column identifiers
    parse_node.c	create nodes for various structures
    parse_oper.c	handle operators in expressions
    parse_param.c	handle Params (for the cases used in the core backend)
    parse_relation.c support routines for tables and column handling
    parse_target.c	handle the result list of the query
    parse_type.c	support routines for data type handling
    parse_utilcmd.c	parse analysis for utility commands (done at execution time)