rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
36,433 Commits 36 Branches 606 Tags 423 MiB
C 86%
PLpgSQL 5.5%
Perl 4.1%
Yacc 1.3%
Makefile 0.7%
Other 2.3%
Go to file
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
config Allow use of "z" flag in our printf calls, and use it where appropriate. 2014-01-23 17:18:33 -05:00
contrib Fix non-equivalence of VARIADIC and non-VARIADIC function call formats. 2014-04-03 22:02:24 -04:00
doc Fix non-equivalence of VARIADIC and non-VARIADIC function call formats. 2014-04-03 22:02:24 -04:00
src Fix non-equivalence of VARIADIC and non-VARIADIC function call formats. 2014-04-03 22:02:24 -04:00
.dir-locals.el Update Emacs configuration 2013-08-13 20:08:44 -04:00
.gitattributes gitattributes: Make syntax compatible with older Git versions 2013-11-12 21:58:46 -05:00
.gitignore Add *.pot to .gitignore 2013-10-19 10:56:52 -04:00
COPYRIGHT Update copyright for 2014 2014-01-07 16:05:30 -05:00
GNUmakefile.in Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:04 -05:00
HISTORY Improve text of stub HISTORY file. 2014-02-12 18:16:17 -05:00
Makefile Allow make check in PL directories 2011-02-15 06:52:12 +02:00
README Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:04 -05:00
README.git Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:04 -05:00
aclocal.m4 Remove cvs keywords from all files. 2010-09-20 22:08:53 +02:00
configure configure.in: Use dnl in place of # where appropriate 2014-02-22 20:42:39 -05:00
configure.in configure.in: Use dnl in place of # where appropriate 2014-02-22 20:42:39 -05:00

README 

PostgreSQL Database Management System
=====================================

This directory contains the source code distribution of the PostgreSQL
database management system.

PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions, foreign keys, subqueries, triggers, user-defined types
and functions.  This distribution also contains C language bindings.

PostgreSQL has many language interfaces, many of which are listed here:

	http://www.postgresql.org/download

See the file INSTALL for instructions on how to build and install
PostgreSQL.  That file also lists supported operating systems and
hardware platforms and contains information regarding any other
software packages that are required to build or run the PostgreSQL
system.  Copyright and license information can be found in the
file COPYRIGHT.  A comprehensive documentation set is included in this
distribution; it can be read as described in the installation
instructions.

The latest version of this software may be obtained at
http://www.postgresql.org/download/.  For more information look at our
web site located at http://www.postgresql.org/.