Tom Lane 29d2f86a31 Allow zero-dimensional (ie, empty) arrays in contrib/ltree operations. ... The main motivation for changing this is bug #4921, in which it's pointed out that it's no longer safe to apply ltree operations to the result of ARRAY(SELECT ...) if the sub-select might return no rows. Before 8.3, the ARRAY() construct would return NULL, which might or might not be helpful but at least it wouldn't result in an error. Now it returns an empty array which results in a failure for no good reason, since the ltree operations are all perfectly capable of dealing with zero-element arrays. As far as I can find, these ltree functions are the only places where zero array dimensionality is rejected unnecessarily. Back-patch to 8.3 to prevent behavioral regression of queries that worked in older releases.		2010-02-24 18:02:24 +00:00
..
data
expected
sql
_ltree_gist.c	Allow zero-dimensional (ie, empty) arrays in contrib/ltree operations.	2010-02-24 18:02:24 +00:00
_ltree_op.c	Allow zero-dimensional (ie, empty) arrays in contrib/ltree operations.	2010-02-24 18:02:24 +00:00
crc32.c
crc32.h
lquery_op.c	Allow zero-dimensional (ie, empty) arrays in contrib/ltree operations.	2010-02-24 18:02:24 +00:00
ltree_gist.c	Allow zero-dimensional (ie, empty) arrays in contrib/ltree operations.	2010-02-24 18:02:24 +00:00
ltree_io.c
ltree_op.c
ltree.h
ltree.sql.in
ltreetest.sql
ltxtquery_io.c
ltxtquery_op.c
Makefile
uninstall_ltree.sql