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
    The initial collations patch treated a COLLATE spec as part of a TypeName,
    following what can only be described as brain fade on the part of the SQL
    committee.  It's a lot more reasonable to treat COLLATE as a syntactically
    separate object, so that it can be added in only the productions where it
    actually belongs, rather than needing to reject it in a boatload of places
    where it doesn't belong (something the original patch mostly failed to do).
    In addition this change lets us meet the spec's requirement to allow
    COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
    behavior for constructs such as "foo::type COLLATE collation".
    
    To do this, pull collation information out of TypeName and put it in
    ColumnDef instead, thus reverting most of the collation-related changes in
    parse_type.c's API.  I made one additional structural change, which was to
    use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
    nodes.  This provides enough room to get rid of the "transform" wart in
    AlterTableCmd too, since the ColumnDef can carry the USING expression
    easily enough.
    
    Also fix some other minor bugs that have crept in in the same areas,
    like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
    
    While at it, document the formerly secret ability to specify a collation
    in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
    ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
    what the default collation selection will be when COLLATE is omitted.
    
    BTW, the three-parameter form of format_type() should go away too,
    since it just contributes to the confusion in this area; but I'll do
    that in a separate patch.
    a051ef69
    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_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)