Tom Lane f68e11f373 Implement subselects in target lists. Also, relax requirement that
subselects can only appear on the righthand side of a binary operator.
That's still true for quantified predicates like x = ANY (SELECT ...),
but a subselect that delivers a single result can now appear anywhere
in an expression.  This is implemented by changing EXPR_SUBLINK sublinks
to represent just the (SELECT ...) expression, without any 'left hand
side' or combining operator --- so they're now more like EXISTS_SUBLINK.
To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink
type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to.
But the grammar will only generate one for a multiple-left-hand-side
row expression.
1999-11-15 02:00:15 +00:00
..
1998-08-23 14:43:46 +00:00

This directory does more than tokenize and parse SQL queries.  It also
creates Query structures for the various complex queries that is passed
to the optimizer and then executor.

parser.c	things start here
scan.l		break query into tokens
scansup.c	handle escapes in input
keywords.c	turn keywords into specific tokens
gram.y		parse the tokens and fill query-type-specific structures
analyze.c	handle post-parse processing for each query type
parse_clause.c	handle clauses like WHERE, ORDER BY, GROUP BY, ...
parse_coerce.c	used for coercing expressions of different types
parse_expr.c	handle expressions like col, col + 3, x = 3 or x = 4
parse_oper.c	handle operations 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 type handling