rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-09-08 23:39:21 +02:00
Code Issues Packages Projects Releases Wiki Activity
c7b3539599
postgresql/src/backend/parser
History
Tom Lane c7b3539599 Fix non-equivalence of VARIADIC and non-VARIADIC function call formats. 
For variadic functions (other than VARIADIC ANY), the syntaxes foo(x,y,...)
and foo(VARIADIC ARRAY[x,y,...]) should be considered equivalent, since the
former is converted to the latter at parse time.  They have indeed been
equivalent, in all releases before 9.3.  However, commit 75b39e790 made an
ill-considered decision to record which syntax had been used in FuncExpr
nodes, and then to make equal() test that in checking node equality ---
which caused the syntaxes to not be seen as equivalent by the planner.
This is the underlying cause of bug #9817 from Dmitry Ryabov.

It might seem that a quick fix would be to make equal() disregard
FuncExpr.funcvariadic, but the same commit made that untenable, because
the field actually *is* semantically significant for some VARIADIC ANY
functions.  This patch instead adopts the approach of redefining
funcvariadic (and aggvariadic, in HEAD) as meaning that the last argument
is a variadic array, whether it got that way by parser intervention or was
supplied explicitly by the user.  Therefore the value will always be true
for non-ANY variadic functions, restoring the principle of equivalence.
(However, the planner will continue to consider use of VARIADIC as a
meaningful difference for VARIADIC ANY functions, even though some such
functions might disregard it.)

In HEAD, this change lets us simplify the decompilation logic in
ruleutils.c, since the funcvariadic/aggvariadic flag tells directly whether
to print VARIADIC.  However, in 9.3 we have to continue to cope with
existing stored rules/views that might contain the previous definition.
Fortunately, this just means no change in ruleutils.c, since its existing
behavior effectively ignores funcvariadic for all cases other than VARIADIC
ANY functions.

In HEAD, bump catversion to reflect the fact that FuncExpr.funcvariadic
changed meanings; this is sort of pro forma, since I don't believe any
built-in views are affected.

Unfortunately, this patch doesn't magically fix everything for affected
9.3 users.  After installing 9.3.5, they might need to recreate their
rules/views/indexes containing variadic function calls in order to get
everything consistent with the new definition.  As in the cited bug,
the symptom of a problem would be failure to use a nominally matching
index that has a variadic function call in its definition.  We'll need
to mention this in the 9.3.5 release notes.
2014-04-03 22:02:24 -04:00
..
.gitignore
analyze.c Disallow LATERAL references to the target table of an UPDATE/DELETE. 2014-01-11 19:03:12 -05:00
check_keywords.pl Update copyright for 2014 2014-01-07 16:05:30 -05:00
gram.y Provide a FORCE NULL option to COPY in CSV mode. 2014-03-04 17:31:59 -05:00
keywords.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
kwlookup.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
Makefile Refactor flex and bison make rules 2012-10-11 06:57:04 -04:00
parse_agg.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_clause.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_coerce.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_collate.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_cte.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_expr.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_func.c Fix non-equivalence of VARIADIC and non-VARIADIC function call formats. 2014-04-03 22:02:24 -04:00
parse_node.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_oper.c Make DROP IF EXISTS more consistently not fail 2014-01-23 14:40:29 -03:00
parse_param.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_relation.c Disallow LATERAL references to the target table of an UPDATE/DELETE. 2014-01-11 19:03:12 -05:00
parse_target.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
parse_type.c Make DROP IF EXISTS more consistently not fail 2014-01-23 14:40:29 -03:00
parse_utilcmd.c Avoid repeated name lookups during table and index DDL. 2014-02-17 09:33:31 -05:00
parser.c Update copyright for 2014 2014-01-07 16:05:30 -05:00
README Revise collation derivation method and expression-tree representation. 2011-03-19 20:30:08 -04:00
scan.l Fix length checking for Unicode identifiers containing escapes (U&"..."). 2014-02-13 14:24:42 -05:00
scansup.c Update copyright for 2014 2014-01-07 16:05:30 -05:00

README 

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)