2009-06-17 23:58:49 +02:00
|
|
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.70 2009/06/17 21:58:48 tgl Exp $ -->
|
2001-01-27 00:40:39 +01:00
|
|
|
|
2002-08-05 21:43:31 +02:00
|
|
|
<sect1 id="arrays">
|
2001-01-27 00:40:39 +01:00
|
|
|
<title>Arrays</title>
|
|
|
|
|
2001-05-13 00:51:36 +02:00
|
|
|
<indexterm>
|
2003-08-31 19:32:24 +02:00
|
|
|
<primary>array</primary>
|
2001-05-13 00:51:36 +02:00
|
|
|
</indexterm>
|
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<para>
|
2001-11-21 06:53:41 +01:00
|
|
|
<productname>PostgreSQL</productname> allows columns of a table to be
|
2001-09-09 19:21:59 +02:00
|
|
|
defined as variable-length multidimensional arrays. Arrays of any
|
Support arrays of composite types, including the rowtypes of regular tables
and views (but not system catalogs, nor sequences or toast tables). Get rid
of the hardwired convention that a type's array type is named exactly "_type",
instead using a new column pg_type.typarray to provide the linkage. (It still
will be named "_type", though, except in odd corner cases such as
maximum-length type names.)
Along the way, make tracking of owner and schema dependencies for types more
uniform: a type directly created by the user has these dependencies, while a
table rowtype or auto-generated array type does not have them, but depends on
its parent object instead.
David Fetter, Andrew Dunstan, Tom Lane
2007-05-11 19:57:14 +02:00
|
|
|
built-in or user-defined base type, enum type, or composite type
|
|
|
|
can be created.
|
|
|
|
Arrays of domains are not yet supported.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<sect2 id="arrays-declaration">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Declaration of Array Types</title>
|
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>array</primary>
|
|
|
|
<secondary>declaration</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<para>
|
|
|
|
To illustrate the use of array types, we create this table:
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2000-03-28 05:39:50 +02:00
|
|
|
CREATE TABLE sal_emp (
|
1998-03-01 09:16:16 +01:00
|
|
|
name text,
|
2001-01-27 00:40:39 +01:00
|
|
|
pay_by_quarter integer[],
|
1998-04-26 06:18:06 +02:00
|
|
|
schedule text[][]
|
1998-03-01 09:16:16 +01:00
|
|
|
);
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
2001-11-19 04:58:25 +01:00
|
|
|
As shown, an array data type is named by appending square brackets
|
2003-03-13 02:30:29 +01:00
|
|
|
(<literal>[]</>) to the data type name of the array elements. The
|
|
|
|
above command will create a table named
|
|
|
|
<structname>sal_emp</structname> with a column of type
|
|
|
|
<type>text</type> (<structfield>name</structfield>), a
|
|
|
|
one-dimensional array of type <type>integer</type>
|
|
|
|
(<structfield>pay_by_quarter</structfield>), which represents the
|
|
|
|
employee's salary by quarter, and a two-dimensional array of
|
|
|
|
<type>text</type> (<structfield>schedule</structfield>), which
|
|
|
|
represents the employee's weekly schedule.
|
2001-01-27 00:40:39 +01:00
|
|
|
</para>
|
2003-08-10 00:50:22 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
The syntax for <command>CREATE TABLE</command> allows the exact size of
|
|
|
|
arrays to be specified, for example:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
CREATE TABLE tictactoe (
|
|
|
|
squares integer[3][3]
|
|
|
|
);
|
|
|
|
</programlisting>
|
|
|
|
|
2009-04-27 18:27:36 +02:00
|
|
|
However, the current implementation ignores any supplied array size
|
|
|
|
limits, i.e., the behavior is the same as for arrays of unspecified
|
2003-08-10 00:50:22 +02:00
|
|
|
length.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
The current implementation does not enforce the declared
|
2003-08-10 00:50:22 +02:00
|
|
|
number of dimensions either. Arrays of a particular element type are
|
|
|
|
all considered to be of the same type, regardless of size or number
|
2009-06-17 23:58:49 +02:00
|
|
|
of dimensions. So, declaring the array size or number of dimensions in
|
|
|
|
<command>CREATE TABLE</command> is simply documentation; it does not
|
2005-11-05 00:14:02 +01:00
|
|
|
affect run-time behavior.
|
2003-08-10 00:50:22 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
An alternative syntax, which conforms to the SQL standard by using
|
2009-06-17 23:58:49 +02:00
|
|
|
the keyword <literal>ARRAY</>, can be used for one-dimensional arrays.
|
2004-11-27 22:27:08 +01:00
|
|
|
<structfield>pay_by_quarter</structfield> could have been defined
|
|
|
|
as:
|
2003-08-10 00:50:22 +02:00
|
|
|
<programlisting>
|
|
|
|
pay_by_quarter integer ARRAY[4],
|
|
|
|
</programlisting>
|
2008-10-29 12:24:53 +01:00
|
|
|
Or, if no array size is to be specified:
|
|
|
|
<programlisting>
|
|
|
|
pay_by_quarter integer ARRAY,
|
|
|
|
</programlisting>
|
2003-08-10 00:50:22 +02:00
|
|
|
As before, however, <productname>PostgreSQL</> does not enforce the
|
2008-10-29 12:24:53 +01:00
|
|
|
size restriction in any case.
|
2003-08-10 00:50:22 +02:00
|
|
|
</para>
|
2003-03-13 02:30:29 +01:00
|
|
|
</sect2>
|
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<sect2 id="arrays-input">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Array Value Input</title>
|
2001-01-27 00:40:39 +01:00
|
|
|
|
2003-11-04 10:55:39 +01:00
|
|
|
<indexterm>
|
|
|
|
<primary>array</primary>
|
|
|
|
<secondary>constant</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To write an array value as a literal constant, enclose the element
|
|
|
|
values within curly braces and separate them by commas. (If you
|
|
|
|
know C, this is not unlike the C syntax for initializing
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
structures.) You can put double quotes around any element value,
|
2003-11-04 10:55:39 +01:00
|
|
|
and must do so if it contains commas or curly braces. (More
|
|
|
|
details appear below.) Thus, the general format of an array
|
|
|
|
constant is the following:
|
|
|
|
<synopsis>
|
|
|
|
'{ <replaceable>val1</replaceable> <replaceable>delim</replaceable> <replaceable>val2</replaceable> <replaceable>delim</replaceable> ... }'
|
|
|
|
</synopsis>
|
|
|
|
where <replaceable>delim</replaceable> is the delimiter character
|
|
|
|
for the type, as recorded in its <literal>pg_type</literal> entry.
|
2004-08-08 07:01:55 +02:00
|
|
|
Among the standard data types provided in the
|
2009-04-27 18:27:36 +02:00
|
|
|
<productname>PostgreSQL</productname> distribution, all use a comma
|
2009-06-17 23:58:49 +02:00
|
|
|
(<literal>,</>), except for type <type>box</> which uses a semicolon
|
2009-04-27 18:27:36 +02:00
|
|
|
(<literal>;</>). Each <replaceable>val</replaceable> is
|
2004-08-08 07:01:55 +02:00
|
|
|
either a constant of the array element type, or a subarray. An example
|
2007-02-01 01:28:19 +01:00
|
|
|
of an array constant is:
|
2003-11-04 10:55:39 +01:00
|
|
|
<programlisting>
|
|
|
|
'{{1,2,3},{4,5,6},{7,8,9}}'
|
|
|
|
</programlisting>
|
|
|
|
This constant is a two-dimensional, 3-by-3 array consisting of
|
|
|
|
three subarrays of integers.
|
|
|
|
</para>
|
|
|
|
|
2005-11-17 23:14:56 +01:00
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
To set an element of an array constant to NULL, write <literal>NULL</>
|
2005-11-17 23:14:56 +01:00
|
|
|
for the element value. (Any upper- or lower-case variant of
|
|
|
|
<literal>NULL</> will do.) If you want an actual string value
|
|
|
|
<quote>NULL</>, you must put double quotes around it.
|
|
|
|
</para>
|
|
|
|
|
2003-11-04 10:55:39 +01:00
|
|
|
<para>
|
|
|
|
(These kinds of array constants are actually only a special case of
|
|
|
|
the generic type constants discussed in <xref
|
|
|
|
linkend="sql-syntax-constants-generic">. The constant is initially
|
|
|
|
treated as a string and passed to the array input conversion
|
|
|
|
routine. An explicit type specification might be necessary.)
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2007-02-01 01:28:19 +01:00
|
|
|
Now we can show some <command>INSERT</command> statements:
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2004-08-05 05:30:44 +02:00
|
|
|
<programlisting>
|
|
|
|
INSERT INTO sal_emp
|
|
|
|
VALUES ('Bill',
|
|
|
|
'{10000, 10000, 10000, 10000}',
|
|
|
|
'{{"meeting", "lunch"}, {"training", "presentation"}}');
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-03-28 05:39:50 +02:00
|
|
|
INSERT INTO sal_emp
|
1998-03-01 09:16:16 +01:00
|
|
|
VALUES ('Carol',
|
|
|
|
'{20000, 25000, 25000, 25000}',
|
2004-08-05 05:30:44 +02:00
|
|
|
'{{"breakfast", "consulting"}, {"meeting", "lunch"}}');
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
2003-11-04 10:55:39 +01:00
|
|
|
</para>
|
|
|
|
|
2003-06-27 02:33:26 +02:00
|
|
|
<para>
|
2004-08-05 05:30:44 +02:00
|
|
|
The result of the previous two inserts looks like this:
|
2005-11-17 23:14:56 +01:00
|
|
|
|
2003-06-27 02:33:26 +02:00
|
|
|
<programlisting>
|
|
|
|
SELECT * FROM sal_emp;
|
2004-08-05 05:30:44 +02:00
|
|
|
name | pay_by_quarter | schedule
|
|
|
|
-------+---------------------------+-------------------------------------------
|
|
|
|
Bill | {10000,10000,10000,10000} | {{meeting,lunch},{training,presentation}}
|
|
|
|
Carol | {20000,25000,25000,25000} | {{breakfast,consulting},{meeting,lunch}}
|
2003-06-27 02:33:26 +02:00
|
|
|
(2 rows)
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
2009-04-27 18:27:36 +02:00
|
|
|
<para>
|
|
|
|
Multidimensional arrays must have matching extents for each
|
|
|
|
dimension. A mismatch causes an error, for example:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
INSERT INTO sal_emp
|
|
|
|
VALUES ('Bill',
|
|
|
|
'{10000, 10000, 10000, 10000}',
|
|
|
|
'{{"meeting", "lunch"}, {"meeting"}}');
|
|
|
|
ERROR: multidimensional arrays must have array expressions with matching dimensions
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
2003-06-27 02:33:26 +02:00
|
|
|
<para>
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
The <literal>ARRAY</> constructor syntax can also be used:
|
2003-06-27 02:33:26 +02:00
|
|
|
<programlisting>
|
|
|
|
INSERT INTO sal_emp
|
|
|
|
VALUES ('Bill',
|
|
|
|
ARRAY[10000, 10000, 10000, 10000],
|
2004-08-05 05:30:44 +02:00
|
|
|
ARRAY[['meeting', 'lunch'], ['training', 'presentation']]);
|
2003-06-27 02:33:26 +02:00
|
|
|
|
|
|
|
INSERT INTO sal_emp
|
|
|
|
VALUES ('Carol',
|
|
|
|
ARRAY[20000, 25000, 25000, 25000],
|
2004-08-05 05:30:44 +02:00
|
|
|
ARRAY[['breakfast', 'consulting'], ['meeting', 'lunch']]);
|
2003-06-27 02:33:26 +02:00
|
|
|
</programlisting>
|
2004-08-05 05:30:44 +02:00
|
|
|
Notice that the array elements are ordinary SQL constants or
|
2003-08-10 00:50:22 +02:00
|
|
|
expressions; for instance, string literals are single quoted, instead of
|
|
|
|
double quoted as they would be in an array literal. The <literal>ARRAY</>
|
2004-08-08 07:01:55 +02:00
|
|
|
constructor syntax is discussed in more detail in
|
|
|
|
<xref linkend="sql-syntax-array-constructors">.
|
2003-06-27 02:33:26 +02:00
|
|
|
</para>
|
2003-03-13 02:30:29 +01:00
|
|
|
</sect2>
|
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<sect2 id="arrays-accessing">
|
2003-08-10 00:50:22 +02:00
|
|
|
<title>Accessing Arrays</title>
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>array</primary>
|
|
|
|
<secondary>accessing</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
Now, we can run some queries on the table.
|
2009-04-27 18:27:36 +02:00
|
|
|
First, we show how to access a single element of an array.
|
2001-01-27 00:40:39 +01:00
|
|
|
This query retrieves the names of the employees whose pay changed in
|
|
|
|
the second quarter:
|
2009-06-17 23:58:49 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2000-03-26 20:32:30 +02:00
|
|
|
SELECT name FROM sal_emp WHERE pay_by_quarter[1] <> pay_by_quarter[2];
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-03-26 20:32:30 +02:00
|
|
|
name
|
|
|
|
-------
|
|
|
|
Carol
|
|
|
|
(1 row)
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2001-11-19 04:58:25 +01:00
|
|
|
The array subscript numbers are written within square brackets.
|
2009-04-27 18:27:36 +02:00
|
|
|
By default <productname>PostgreSQL</productname> uses a
|
2002-11-11 21:14:04 +01:00
|
|
|
one-based numbering convention for arrays, that is,
|
2001-11-28 21:49:10 +01:00
|
|
|
an array of <replaceable>n</> elements starts with <literal>array[1]</literal> and
|
|
|
|
ends with <literal>array[<replaceable>n</>]</literal>.
|
2001-01-27 00:40:39 +01:00
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<para>
|
|
|
|
This query retrieves the third quarter pay of all employees:
|
2009-06-17 23:58:49 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2000-03-26 20:32:30 +02:00
|
|
|
SELECT pay_by_quarter[3] FROM sal_emp;
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-03-26 20:32:30 +02:00
|
|
|
pay_by_quarter
|
|
|
|
----------------
|
|
|
|
10000
|
|
|
|
25000
|
|
|
|
(2 rows)
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
We can also access arbitrary rectangular slices of an array, or
|
|
|
|
subarrays. An array slice is denoted by writing
|
2002-11-11 21:14:04 +01:00
|
|
|
<literal><replaceable>lower-bound</replaceable>:<replaceable>upper-bound</replaceable></literal>
|
2003-03-13 02:30:29 +01:00
|
|
|
for one or more array dimensions. For example, this query retrieves the first
|
2002-11-11 21:14:04 +01:00
|
|
|
item on Bill's schedule for the first two days of the week:
|
2009-06-17 23:58:49 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2000-03-26 20:32:30 +02:00
|
|
|
SELECT schedule[1:2][1:1] FROM sal_emp WHERE name = 'Bill';
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2004-08-05 05:30:44 +02:00
|
|
|
schedule
|
|
|
|
------------------------
|
|
|
|
{{meeting},{training}}
|
2000-03-26 20:32:30 +02:00
|
|
|
(1 row)
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2009-04-27 18:27:36 +02:00
|
|
|
If any dimension is written as a slice, i.e., contains a colon, then all
|
2007-03-02 07:01:01 +01:00
|
|
|
dimensions are treated as slices. Any dimension that has only a single
|
|
|
|
number (no colon) is treated as being from <literal>1</>
|
2007-02-20 15:34:25 +01:00
|
|
|
to the number specified. For example, <literal>[2]</> is treated as
|
2007-03-02 07:01:01 +01:00
|
|
|
<literal>[1:2]</>, as in this example:
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2003-06-27 02:33:26 +02:00
|
|
|
SELECT schedule[1:2][2] FROM sal_emp WHERE name = 'Bill';
|
2004-08-05 05:30:44 +02:00
|
|
|
|
|
|
|
schedule
|
|
|
|
-------------------------------------------
|
|
|
|
{{meeting,lunch},{training,presentation}}
|
2003-06-27 02:33:26 +02:00
|
|
|
(1 row)
|
|
|
|
</programlisting>
|
2008-03-26 15:43:20 +01:00
|
|
|
|
2008-03-26 17:34:47 +01:00
|
|
|
To avoid confusion with the non-slice case, it's best to use slice syntax
|
|
|
|
for all dimensions, e.g., <literal>[1:2][1:1]</>, not <literal>[2][1:1]</>.
|
2003-06-27 02:33:26 +02:00
|
|
|
</para>
|
|
|
|
|
2005-02-06 21:59:30 +01:00
|
|
|
<para>
|
2005-11-17 23:14:56 +01:00
|
|
|
An array subscript expression will return null if either the array itself or
|
|
|
|
any of the subscript expressions are null. Also, null is returned if a
|
|
|
|
subscript is outside the array bounds (this case does not raise an error).
|
|
|
|
For example, if <literal>schedule</>
|
2005-02-06 21:59:30 +01:00
|
|
|
currently has the dimensions <literal>[1:3][1:2]</> then referencing
|
|
|
|
<literal>schedule[3][3]</> yields NULL. Similarly, an array reference
|
|
|
|
with the wrong number of subscripts yields a null rather than an error.
|
2005-11-17 23:14:56 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
An array slice expression likewise yields null if the array itself or
|
2009-04-27 18:27:36 +02:00
|
|
|
any of the subscript expressions are null. However, in other
|
2005-11-17 23:14:56 +01:00
|
|
|
cases such as selecting an array slice that
|
|
|
|
is completely outside the current array bounds, a slice expression
|
2008-03-26 15:43:20 +01:00
|
|
|
yields an empty (zero-dimensional) array instead of null. (This
|
|
|
|
does not match non-slice behavior and is done for historical reasons.)
|
2005-11-17 23:14:56 +01:00
|
|
|
If the requested slice partially overlaps the array bounds, then it
|
2009-04-27 18:27:36 +02:00
|
|
|
is silently reduced to just the overlapping region instead of
|
|
|
|
returning null.
|
2005-02-06 21:59:30 +01:00
|
|
|
</para>
|
|
|
|
|
2003-06-27 02:33:26 +02:00
|
|
|
<para>
|
2003-08-10 00:50:22 +02:00
|
|
|
The current dimensions of any array value can be retrieved with the
|
|
|
|
<function>array_dims</function> function:
|
|
|
|
|
2003-06-27 02:33:26 +02:00
|
|
|
<programlisting>
|
2003-08-10 00:50:22 +02:00
|
|
|
SELECT array_dims(schedule) FROM sal_emp WHERE name = 'Carol';
|
|
|
|
|
|
|
|
array_dims
|
|
|
|
------------
|
2007-06-07 16:49:56 +02:00
|
|
|
[1:2][1:2]
|
2003-08-10 00:50:22 +02:00
|
|
|
(1 row)
|
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
<function>array_dims</function> produces a <type>text</type> result,
|
2009-04-27 18:27:36 +02:00
|
|
|
which is convenient for people to read but perhaps inconvenient
|
2003-08-10 00:50:22 +02:00
|
|
|
for programs. Dimensions can also be retrieved with
|
|
|
|
<function>array_upper</function> and <function>array_lower</function>,
|
|
|
|
which return the upper and lower bound of a
|
2007-02-01 01:28:19 +01:00
|
|
|
specified array dimension, respectively:
|
2003-08-10 00:50:22 +02:00
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
SELECT array_upper(schedule, 1) FROM sal_emp WHERE name = 'Carol';
|
|
|
|
|
|
|
|
array_upper
|
|
|
|
-------------
|
|
|
|
2
|
2003-06-27 02:33:26 +02:00
|
|
|
(1 row)
|
2008-11-12 14:09:28 +01:00
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
<function>array_length</function> will return the length of a specified
|
|
|
|
array dimension:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
SELECT array_length(schedule, 1) FROM sal_emp WHERE name = 'Carol';
|
|
|
|
|
|
|
|
array_length
|
|
|
|
--------------
|
|
|
|
2
|
|
|
|
(1 row)
|
2003-06-27 02:33:26 +02:00
|
|
|
</programlisting>
|
2001-01-27 00:40:39 +01:00
|
|
|
</para>
|
2003-08-10 00:50:22 +02:00
|
|
|
</sect2>
|
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<sect2 id="arrays-modifying">
|
2003-08-10 00:50:22 +02:00
|
|
|
<title>Modifying Arrays</title>
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>array</primary>
|
|
|
|
<secondary>modifying</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<para>
|
|
|
|
An array value can be replaced completely:
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2000-03-28 05:39:50 +02:00
|
|
|
UPDATE sal_emp SET pay_by_quarter = '{25000,25000,27000,27000}'
|
|
|
|
WHERE name = 'Carol';
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2003-08-10 00:50:22 +02:00
|
|
|
or using the <literal>ARRAY</literal> expression syntax:
|
2003-06-27 02:33:26 +02:00
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
UPDATE sal_emp SET pay_by_quarter = ARRAY[25000,25000,27000,27000]
|
|
|
|
WHERE name = 'Carol';
|
|
|
|
</programlisting>
|
|
|
|
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
An array can also be updated at a single element:
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2000-03-28 05:39:50 +02:00
|
|
|
UPDATE sal_emp SET pay_by_quarter[4] = 15000
|
|
|
|
WHERE name = 'Bill';
|
2001-01-27 00:40:39 +01:00
|
|
|
</programListing>
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
or updated in a slice:
|
2000-03-28 05:39:50 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<programlisting>
|
2000-03-28 05:39:50 +02:00
|
|
|
UPDATE sal_emp SET pay_by_quarter[1:2] = '{27000,27000}'
|
|
|
|
WHERE name = 'Carol';
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
2003-06-27 02:33:26 +02:00
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
A stored array value can be enlarged by assigning to elements not already
|
2006-09-29 23:22:21 +02:00
|
|
|
present. Any positions between those previously present and the newly
|
2009-04-27 18:27:36 +02:00
|
|
|
assigned elements will be filled with nulls. For example, if array
|
2006-09-29 23:22:21 +02:00
|
|
|
<literal>myarray</> currently has 4 elements, it will have six
|
2009-04-27 18:27:36 +02:00
|
|
|
elements after an update that assigns to <literal>myarray[6]</>;
|
|
|
|
<literal>myarray[5]</> will contain null.
|
2003-08-10 00:50:22 +02:00
|
|
|
Currently, enlargement in this fashion is only allowed for one-dimensional
|
|
|
|
arrays, not multidimensional arrays.
|
2001-01-27 00:40:39 +01:00
|
|
|
</para>
|
|
|
|
|
2002-03-17 20:59:57 +01:00
|
|
|
<para>
|
2005-11-17 23:14:56 +01:00
|
|
|
Subscripted assignment allows creation of arrays that do not use one-based
|
2003-08-10 00:50:22 +02:00
|
|
|
subscripts. For example one might assign to <literal>myarray[-2:7]</> to
|
2009-04-27 18:27:36 +02:00
|
|
|
create an array with subscript values from -2 to 7.
|
2002-03-17 20:59:57 +01:00
|
|
|
</para>
|
|
|
|
|
2003-06-27 02:33:26 +02:00
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
New array values can also be constructed using the concatenation operator,
|
2007-02-01 01:28:19 +01:00
|
|
|
<literal>||</literal>:
|
2003-06-27 02:33:26 +02:00
|
|
|
<programlisting>
|
|
|
|
SELECT ARRAY[1,2] || ARRAY[3,4];
|
2003-08-19 08:06:48 +02:00
|
|
|
?column?
|
|
|
|
-----------
|
|
|
|
{1,2,3,4}
|
2003-06-27 02:33:26 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT ARRAY[5,6] || ARRAY[[1,2],[3,4]];
|
|
|
|
?column?
|
|
|
|
---------------------
|
|
|
|
{{5,6},{1,2},{3,4}}
|
|
|
|
(1 row)
|
|
|
|
</programlisting>
|
2003-08-19 08:06:48 +02:00
|
|
|
</para>
|
2003-06-27 02:33:26 +02:00
|
|
|
|
2003-08-19 08:06:48 +02:00
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
The concatenation operator allows a single element to be pushed onto the
|
2003-08-10 00:50:22 +02:00
|
|
|
beginning or end of a one-dimensional array. It also accepts two
|
2003-06-27 02:33:26 +02:00
|
|
|
<replaceable>N</>-dimensional arrays, or an <replaceable>N</>-dimensional
|
2003-08-19 08:06:48 +02:00
|
|
|
and an <replaceable>N+1</>-dimensional array.
|
|
|
|
</para>
|
2003-06-27 02:33:26 +02:00
|
|
|
|
2003-08-19 08:06:48 +02:00
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
When a single element is pushed onto either the beginning or end of a
|
2005-11-19 02:50:08 +01:00
|
|
|
one-dimensional array, the result is an array with the same lower bound
|
|
|
|
subscript as the array operand. For example:
|
2003-06-27 02:33:26 +02:00
|
|
|
<programlisting>
|
2005-11-19 02:50:08 +01:00
|
|
|
SELECT array_dims(1 || '[0:1]={2,3}'::int[]);
|
2003-06-27 02:33:26 +02:00
|
|
|
array_dims
|
|
|
|
------------
|
|
|
|
[0:2]
|
|
|
|
(1 row)
|
2003-08-19 08:06:48 +02:00
|
|
|
|
|
|
|
SELECT array_dims(ARRAY[1,2] || 3);
|
|
|
|
array_dims
|
|
|
|
------------
|
|
|
|
[1:3]
|
|
|
|
(1 row)
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
When two arrays with an equal number of dimensions are concatenated, the
|
2003-11-01 02:56:29 +01:00
|
|
|
result retains the lower bound subscript of the left-hand operand's outer
|
|
|
|
dimension. The result is an array comprising every element of the left-hand
|
|
|
|
operand followed by every element of the right-hand operand. For example:
|
2003-08-19 08:06:48 +02:00
|
|
|
<programlisting>
|
|
|
|
SELECT array_dims(ARRAY[1,2] || ARRAY[3,4,5]);
|
|
|
|
array_dims
|
|
|
|
------------
|
|
|
|
[1:5]
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT array_dims(ARRAY[[1,2],[3,4]] || ARRAY[[5,6],[7,8],[9,0]]);
|
|
|
|
array_dims
|
|
|
|
------------
|
|
|
|
[1:5][1:2]
|
|
|
|
(1 row)
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
When an <replaceable>N</>-dimensional array is pushed onto the beginning
|
2003-08-19 08:06:48 +02:00
|
|
|
or end of an <replaceable>N+1</>-dimensional array, the result is
|
|
|
|
analogous to the element-array case above. Each <replaceable>N</>-dimensional
|
|
|
|
sub-array is essentially an element of the <replaceable>N+1</>-dimensional
|
|
|
|
array's outer dimension. For example:
|
|
|
|
<programlisting>
|
|
|
|
SELECT array_dims(ARRAY[1,2] || ARRAY[[3,4],[5,6]]);
|
|
|
|
array_dims
|
|
|
|
------------
|
2005-11-19 02:50:08 +01:00
|
|
|
[1:3][1:2]
|
2003-08-19 08:06:48 +02:00
|
|
|
(1 row)
|
2003-06-27 02:33:26 +02:00
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-08-10 00:50:22 +02:00
|
|
|
An array can also be constructed by using the functions
|
2003-06-27 02:33:26 +02:00
|
|
|
<function>array_prepend</function>, <function>array_append</function>,
|
|
|
|
or <function>array_cat</function>. The first two only support one-dimensional
|
|
|
|
arrays, but <function>array_cat</function> supports multidimensional arrays.
|
|
|
|
|
|
|
|
Note that the concatenation operator discussed above is preferred over
|
2009-04-27 18:27:36 +02:00
|
|
|
direct use of these functions. In fact, these functions primarily exist for use
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
in implementing the concatenation operator. However, they might be directly
|
2003-06-27 02:33:26 +02:00
|
|
|
useful in the creation of user-defined aggregates. Some examples:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
SELECT array_prepend(1, ARRAY[2,3]);
|
|
|
|
array_prepend
|
|
|
|
---------------
|
|
|
|
{1,2,3}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT array_append(ARRAY[1,2], 3);
|
|
|
|
array_append
|
|
|
|
--------------
|
|
|
|
{1,2,3}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT array_cat(ARRAY[1,2], ARRAY[3,4]);
|
2003-08-19 08:06:48 +02:00
|
|
|
array_cat
|
|
|
|
-----------
|
|
|
|
{1,2,3,4}
|
2003-06-27 02:33:26 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT array_cat(ARRAY[[1,2],[3,4]], ARRAY[5,6]);
|
|
|
|
array_cat
|
|
|
|
---------------------
|
|
|
|
{{1,2},{3,4},{5,6}}
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT array_cat(ARRAY[5,6], ARRAY[[1,2],[3,4]]);
|
|
|
|
array_cat
|
|
|
|
---------------------
|
|
|
|
{{5,6},{1,2},{3,4}}
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
2003-03-13 02:30:29 +01:00
|
|
|
</sect2>
|
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<sect2 id="arrays-searching">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Searching in Arrays</title>
|
2001-01-27 00:40:39 +01:00
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>array</primary>
|
|
|
|
<secondary>searching</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
To search for a value in an array, each value must be checked.
|
|
|
|
This can be done manually, if you know the size of the array.
|
2003-03-13 02:30:29 +01:00
|
|
|
For example:
|
2001-01-27 00:40:39 +01:00
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
SELECT * FROM sal_emp WHERE pay_by_quarter[1] = 10000 OR
|
|
|
|
pay_by_quarter[2] = 10000 OR
|
|
|
|
pay_by_quarter[3] = 10000 OR
|
|
|
|
pay_by_quarter[4] = 10000;
|
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
However, this quickly becomes tedious for large arrays, and is not
|
2009-04-27 18:27:36 +02:00
|
|
|
helpful if the size of the array is unknown. An alternative method is
|
2003-08-10 00:50:22 +02:00
|
|
|
described in <xref linkend="functions-comparisons">. The above
|
|
|
|
query could be replaced by:
|
2001-01-27 00:40:39 +01:00
|
|
|
|
|
|
|
<programlisting>
|
2003-08-10 00:50:22 +02:00
|
|
|
SELECT * FROM sal_emp WHERE 10000 = ANY (pay_by_quarter);
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
|
|
|
|
2009-04-27 18:27:36 +02:00
|
|
|
In addition, you can find rows where the array has all values
|
2003-08-10 00:50:22 +02:00
|
|
|
equal to 10000 with:
|
2001-01-27 00:40:39 +01:00
|
|
|
|
|
|
|
<programlisting>
|
2003-08-10 00:50:22 +02:00
|
|
|
SELECT * FROM sal_emp WHERE 10000 = ALL (pay_by_quarter);
|
2001-01-27 00:40:39 +01:00
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
2008-04-28 16:48:58 +02:00
|
|
|
<para>
|
|
|
|
Alternatively, the <function>generate_subscripts</> function can be used.
|
|
|
|
For example:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
SELECT * FROM
|
|
|
|
(SELECT pay_by_quarter,
|
|
|
|
generate_subscripts(pay_by_quarter, 1) AS s
|
|
|
|
FROM sal_emp) AS foo
|
|
|
|
WHERE pay_by_quarter[s] = 10000;
|
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
This function is described in <xref linkend="functions-srf-subscripts">.
|
|
|
|
</para>
|
|
|
|
|
2001-01-27 00:40:39 +01:00
|
|
|
<tip>
|
|
|
|
<para>
|
2003-08-10 00:50:22 +02:00
|
|
|
Arrays are not sets; searching for specific array elements
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
can be a sign of database misdesign. Consider
|
2003-08-10 00:50:22 +02:00
|
|
|
using a separate table with a row for each item that would be an
|
|
|
|
array element. This will be easier to search, and is likely to
|
2009-04-27 18:27:36 +02:00
|
|
|
scale better for a large number of elements.
|
2001-01-27 00:40:39 +01:00
|
|
|
</para>
|
|
|
|
</tip>
|
2003-03-13 02:30:29 +01:00
|
|
|
</sect2>
|
2001-01-27 00:40:39 +01:00
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<sect2 id="arrays-io">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Array Input and Output Syntax</title>
|
2001-11-19 04:58:25 +01:00
|
|
|
|
2008-04-27 06:33:27 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>array</primary>
|
|
|
|
<secondary>I/O</secondary>
|
|
|
|
</indexterm>
|
|
|
|
|
2002-03-17 20:59:57 +01:00
|
|
|
<para>
|
2003-08-10 00:50:22 +02:00
|
|
|
The external text representation of an array value consists of items that
|
2002-03-17 20:59:57 +01:00
|
|
|
are interpreted according to the I/O conversion rules for the array's
|
|
|
|
element type, plus decoration that indicates the array structure.
|
|
|
|
The decoration consists of curly braces (<literal>{</> and <literal>}</>)
|
|
|
|
around the array value plus delimiter characters between adjacent items.
|
|
|
|
The delimiter character is usually a comma (<literal>,</>) but can be
|
|
|
|
something else: it is determined by the <literal>typdelim</> setting
|
2009-06-17 23:58:49 +02:00
|
|
|
for the array's element type. Among the standard data types provided
|
|
|
|
in the <productname>PostgreSQL</productname> distribution, all use a comma,
|
|
|
|
except for type <type>box</>, which uses a semicolon (<literal>;</>).
|
2009-04-27 18:27:36 +02:00
|
|
|
In a multidimensional array, each dimension (row, plane,
|
2002-03-17 20:59:57 +01:00
|
|
|
cube, etc.) gets its own level of curly braces, and delimiters
|
|
|
|
must be written between adjacent curly-braced entities of the same level.
|
2004-08-08 07:01:55 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The array output routine will put double quotes around element values
|
2005-11-17 23:14:56 +01:00
|
|
|
if they are empty strings, contain curly braces, delimiter characters,
|
|
|
|
double quotes, backslashes, or white space, or match the word
|
|
|
|
<literal>NULL</>. Double quotes and backslashes
|
2004-08-08 07:01:55 +02:00
|
|
|
embedded in element values will be backslash-escaped. For numeric
|
|
|
|
data types it is safe to assume that double quotes will never appear, but
|
2009-04-27 18:27:36 +02:00
|
|
|
for textual data types one should be prepared to cope with either the presence
|
2006-04-23 05:39:52 +02:00
|
|
|
or absence of quotes.
|
2002-03-17 20:59:57 +01:00
|
|
|
</para>
|
2003-06-27 02:33:26 +02:00
|
|
|
|
2004-08-05 05:30:44 +02:00
|
|
|
<para>
|
|
|
|
By default, the lower bound index value of an array's dimensions is
|
2005-11-17 23:14:56 +01:00
|
|
|
set to one. To represent arrays with other lower bounds, the array
|
|
|
|
subscript ranges can be specified explicitly before writing the
|
|
|
|
array contents.
|
2004-12-23 06:37:40 +01:00
|
|
|
This decoration consists of square brackets (<literal>[]</>)
|
|
|
|
around each array dimension's lower and upper bounds, with
|
|
|
|
a colon (<literal>:</>) delimiter character in between. The
|
|
|
|
array dimension decoration is followed by an equal sign (<literal>=</>).
|
|
|
|
For example:
|
2004-08-05 05:30:44 +02:00
|
|
|
<programlisting>
|
|
|
|
SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
|
|
|
|
FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss;
|
|
|
|
|
|
|
|
e1 | e2
|
|
|
|
----+----
|
|
|
|
1 | 6
|
|
|
|
(1 row)
|
|
|
|
</programlisting>
|
2005-11-17 23:14:56 +01:00
|
|
|
The array output routine will include explicit dimensions in its result
|
|
|
|
only when there are one or more lower bounds different from one.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
If the value written for an element is <literal>NULL</> (in any case
|
|
|
|
variant), the element is taken to be NULL. The presence of any quotes
|
|
|
|
or backslashes disables this and allows the literal string value
|
|
|
|
<quote>NULL</> to be entered. Also, for backwards compatibility with
|
|
|
|
pre-8.2 versions of <productname>PostgreSQL</>, the <xref
|
2009-04-27 18:27:36 +02:00
|
|
|
linkend="guc-array-nulls"> configuration parameter can be turned
|
2005-11-17 23:14:56 +01:00
|
|
|
<literal>off</> to suppress recognition of <literal>NULL</> as a NULL.
|
2004-08-05 05:30:44 +02:00
|
|
|
</para>
|
|
|
|
|
2003-06-27 02:33:26 +02:00
|
|
|
<para>
|
2009-04-27 18:27:36 +02:00
|
|
|
As shown previously, when writing an array value you can use double
|
2004-08-08 07:01:55 +02:00
|
|
|
quotes around any individual array element. You <emphasis>must</> do so
|
|
|
|
if the element value would otherwise confuse the array-value parser.
|
2009-06-17 23:58:49 +02:00
|
|
|
For example, elements containing curly braces, commas (or the data type's
|
2009-04-27 18:27:36 +02:00
|
|
|
delimiter character), double quotes, backslashes, or leading or trailing
|
2005-11-17 23:14:56 +01:00
|
|
|
whitespace must be double-quoted. Empty strings and strings matching the
|
|
|
|
word <literal>NULL</> must be quoted, too. To put a double quote or
|
2007-01-30 23:29:23 +01:00
|
|
|
backslash in a quoted array element value, use escape string syntax
|
2009-04-27 18:27:36 +02:00
|
|
|
and precede it with a backslash. Alternatively, you can avoid quotes and use
|
2007-01-30 23:29:23 +01:00
|
|
|
backslash-escaping to protect all data characters that would otherwise
|
|
|
|
be taken as array syntax.
|
2001-11-29 22:02:41 +01:00
|
|
|
</para>
|
|
|
|
|
2002-03-17 20:59:57 +01:00
|
|
|
<para>
|
2009-06-17 23:58:49 +02:00
|
|
|
You can add whitespace before a left brace or after a right
|
2009-04-27 18:27:36 +02:00
|
|
|
brace. You can also add whitespace before or after any individual item
|
2004-08-08 07:01:55 +02:00
|
|
|
string. In all of these cases the whitespace will be ignored. However,
|
2004-12-23 06:37:40 +01:00
|
|
|
whitespace within double-quoted elements, or surrounded on both sides by
|
|
|
|
non-whitespace characters of an element, is not ignored.
|
2002-03-17 20:59:57 +01:00
|
|
|
</para>
|
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<note>
|
2001-11-29 22:02:41 +01:00
|
|
|
<para>
|
2002-11-11 21:14:04 +01:00
|
|
|
Remember that what you write in an SQL command will first be interpreted
|
2001-11-29 22:02:41 +01:00
|
|
|
as a string literal, and then as an array. This doubles the number of
|
|
|
|
backslashes you need. For example, to insert a <type>text</> array
|
2007-02-01 01:28:19 +01:00
|
|
|
value containing a backslash and a double quote, you'd need to write:
|
2001-11-29 22:02:41 +01:00
|
|
|
<programlisting>
|
2007-01-30 23:29:23 +01:00
|
|
|
INSERT ... VALUES (E'{"\\\\","\\""}');
|
2001-11-29 22:02:41 +01:00
|
|
|
</programlisting>
|
2007-01-30 23:29:23 +01:00
|
|
|
The escape string processor removes one level of backslashes, so that
|
2001-11-29 22:02:41 +01:00
|
|
|
what arrives at the array-value parser looks like <literal>{"\\","\""}</>.
|
2002-01-20 23:19:57 +01:00
|
|
|
In turn, the strings fed to the <type>text</> data type's input routine
|
2001-11-29 22:02:41 +01:00
|
|
|
become <literal>\</> and <literal>"</> respectively. (If we were working
|
2002-01-20 23:19:57 +01:00
|
|
|
with a data type whose input routine also treated backslashes specially,
|
2001-11-29 22:02:41 +01:00
|
|
|
<type>bytea</> for example, we might need as many as eight backslashes
|
2002-11-11 21:14:04 +01:00
|
|
|
in the command to get one backslash into the stored array element.)
|
2007-01-30 23:29:23 +01:00
|
|
|
Dollar quoting (see <xref linkend="sql-syntax-dollar-quoting">) can be
|
2004-12-23 06:37:40 +01:00
|
|
|
used to avoid the need to double backslashes.
|
2001-11-29 22:02:41 +01:00
|
|
|
</para>
|
2003-03-13 02:30:29 +01:00
|
|
|
</note>
|
2003-08-10 00:50:22 +02:00
|
|
|
|
|
|
|
<tip>
|
|
|
|
<para>
|
2004-08-08 07:01:55 +02:00
|
|
|
The <literal>ARRAY</> constructor syntax (see
|
|
|
|
<xref linkend="sql-syntax-array-constructors">) is often easier to work
|
|
|
|
with than the array-literal syntax when writing array values in SQL
|
|
|
|
commands. In <literal>ARRAY</>, individual element values are written the
|
|
|
|
same way they would be written when not members of an array.
|
2003-08-10 00:50:22 +02:00
|
|
|
</para>
|
|
|
|
</tip>
|
2003-03-13 02:30:29 +01:00
|
|
|
</sect2>
|
2001-11-29 22:02:41 +01:00
|
|
|
|
2002-08-05 21:43:31 +02:00
|
|
|
</sect1>
|