Files
postgresql/src/backend/parser
Tom Lane 0aed62fea9 Better solution to the IN-list issue: instead of having an arbitrary cutoff,
treat Var and non-Var IN-list items differently.  Only non-Var items are
candidates to go into an ANY(ARRAY) construct --- we put all Vars as separate
OR conditions on the grounds that that leaves more scope for optimization.
Per suggestion from Robert Haas.
2008-10-26 02:46:25 +00:00
..

$PostgreSQL: pgsql/src/backend/parser/README,v 1.10 2008/04/09 01:00:46 momjian Exp $

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
keywords.c	turn keywords into specific tokens
gram.y		parse the tokens and fill query-type-specific structures
analyze.c	top level of parse analysis for optimizable queries
parse_clause.c	handle clauses like WHERE, ORDER BY, GROUP BY, ...
parse_coerce.c	handle coercing expressions to different data types
parse_expr.c	handle expressions like col, col + 3, x = 3 or x = 4
parse_oper.c	handle operators in expressions
parse_agg.c	handle aggregates, like SUM(col1),  AVG(col2), ...
parse_func.c	handle functions, table.column and column identifiers
parse_node.c	create nodes for various structures
parse_target.c	handle the result list of the query
parse_relation.c support routines for tables and column handling
parse_type.c	support routines for data type handling
parse_utilcmd.c	parse analysis for utility commands (done at execution time)