Tom Lane 772c5ba31f Repair incorrect check for coercion of unknown literal to ANYARRAY, a bug
I introduced in 7.4.1 :-(.  It's correct to allow unknown to be coerced to
ANY or ANYELEMENT, since it's a real-enough data type, but it most certainly
isn't an array datatype.  This can cause a backend crash but AFAICT is not
exploitable as a security hole.  Per report from Michael Fuhr.

Note: as fixed in HEAD, this changes a constant in the pg_stats view,
resulting in a change in the expected regression outputs.  The back-branch
patches have been hacked to avoid that, so that pre-existing installations
won't start failing their regression tests.
2006-10-11 20:21:04 +00:00
..
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +00:00
2006-10-04 00:30:14 +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