Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 0a9b042

Browse files
committed
Improve documentation about array concat operator vs. underlying functions.
The documentation implied that there was seldom any reason to use the array_append, array_prepend, and array_cat functions directly. But that's not really true, because they can help make it clear which case is meant, which the || operator can't do since it's overloaded to represent all three cases. Add some discussion and examples illustrating the potentially confusing behavior that can ensue if the parser misinterprets what was meant. Per a complaint from Michael Herold. Back-patch to 9.2, which is where || started to behave this way.
1 parent 9c39d7a commit 0a9b042

File tree

1 file changed

+40
-5
lines changed

1 file changed

+40
-5
lines changed

doc/src/sgml/array.sgml

Lines changed: 40 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -481,11 +481,7 @@ SELECT array_dims(ARRAY[1,2] || ARRAY[[3,4],[5,6]]);
481481
<function>array_prepend</function>, <function>array_append</function>,
482482
or <function>array_cat</function>. The first two only support one-dimensional
483483
arrays, but <function>array_cat</function> supports multidimensional arrays.
484-
485-
Note that the concatenation operator discussed above is preferred over
486-
direct use of these functions. In fact, these functions primarily exist for use
487-
in implementing the concatenation operator. However, they might be directly
488-
useful in the creation of user-defined aggregates. Some examples:
484+
Some examples:
489485

490486
<programlisting>
491487
SELECT array_prepend(1, ARRAY[2,3]);
@@ -518,6 +514,45 @@ SELECT array_cat(ARRAY[5,6], ARRAY[[1,2],[3,4]]);
518514
{{5,6},{1,2},{3,4}}
519515
</programlisting>
520516
</para>
517+
518+
<para>
519+
In simple cases, the concatenation operator discussed above is preferred
520+
over direct use of these functions. However, because the concatenation
521+
operator is overloaded to serve all three cases, there are situations where
522+
use of one of the functions is helpful to avoid ambiguity. For example
523+
consider:
524+
525+
<programlisting>
526+
SELECT ARRAY[1, 2] || '{3, 4}'; -- the untyped literal is taken as an array
527+
?column?
528+
-----------
529+
{1,2,3,4}
530+
531+
SELECT ARRAY[1, 2] || '7'; -- so is this one
532+
ERROR: malformed array literal: "7"
533+
534+
SELECT ARRAY[1, 2] || NULL; -- so is an undecorated NULL
535+
?column?
536+
----------
537+
{1,2}
538+
(1 row)
539+
540+
SELECT array_append(ARRAY[1, 2], NULL); -- this might have been meant
541+
array_append
542+
--------------
543+
{1,2,NULL}
544+
</programlisting>
545+
546+
In the examples above, the parser sees an integer array on one side of the
547+
concatenation operator, and a constant of undetermined type on the other.
548+
The heuristic it uses to resolve the constant's type is to assume it's of
549+
the same type as the operator's other input &mdash; in this case,
550+
integer array. So the concatenation operator is presumed to
551+
represent <function>array_cat</>, not <function>array_append</>. When
552+
that's the wrong choice, it could be fixed by casting the constant to the
553+
array's element type; but explicit use of <function>array_append</> might
554+
be a preferable solution.
555+
</para>
521556
</sect2>
522557

523558
<sect2 id="arrays-searching">

0 commit comments

Comments
 (0)