Tom Lane 6566e37e02 Move some declarations in the raw-parser header files to create a clearer
distinction between the external API (parser.h) and declarations that only
need to be visible within the raw parser code (gramparse.h, which now is only
included by parser.c, gram.y, scan.l, and keywords.c).  This is in preparation
for the upcoming change to a reentrant lexer, which will require referencing
YYSTYPE in the declarations of base_yylex and filtered_base_yylex, hence
gram.h will have to be included by gramparse.h.  We don't want any more files
than absolutely necessary to depend on gram.h, so some cleanup is called for.
2009-07-12 17:12:34 +00:00
..
2009-01-01 17:24:05 +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)