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 existence of a btree opclass accepting composite types caused us to
    assume that every composite type is sortable.  This isn't true of course;
    we need to check if the column types are all sortable.  There was logic
    for this for the case of array comparison (ie, check that the element
    type is sortable), but we missed the point for rowtypes.  Per Teodor's
    report of an ANALYZE failure for an unsortable composite type.
    
    Rather than just add some more ad-hoc logic for this, I moved knowledge of
    the issue into typcache.c.  The typcache will now only report out array_eq,
    record_cmp, and friends as usable operators if the array or composite type
    will work with those functions.
    
    Unfortunately we don't have enough info to do this for anonymous RECORD
    types; in that case, just assume it will work, and take the runtime failure
    as before if it doesn't.
    
    This patch might be a candidate for back-patching at some point, but
    given the lack of complaints from the field, I'd rather just test it in
    HEAD for now.
    
    Note: most of the places touched in this patch will need further work
    when we get around to supporting hashing of record types.
    ea8e42f3
    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)