1999-07-22 17:09:15 +02:00
|
|
|
<!--
|
2010-09-20 22:08:53 +02:00
|
|
|
doc/src/sgml/ref/update.sgml
|
2001-12-08 04:24:40 +01:00
|
|
|
PostgreSQL documentation
|
1999-07-22 17:09:15 +02:00
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-update">
|
2014-02-24 03:25:35 +01:00
|
|
|
<indexterm zone="sql-update">
|
|
|
|
<primary>UPDATE</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
1999-07-14 22:32:59 +02:00
|
|
|
<refmeta>
|
2010-04-03 09:23:02 +02:00
|
|
|
<refentrytitle>UPDATE</refentrytitle>
|
2008-11-14 11:22:48 +01:00
|
|
|
<manvolnum>7</manvolnum>
|
1999-07-14 22:32:59 +02:00
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
2003-04-27 01:56:51 +02:00
|
|
|
|
1999-07-14 22:32:59 +02:00
|
|
|
<refnamediv>
|
2003-04-27 01:56:51 +02:00
|
|
|
<refname>UPDATE</refname>
|
|
|
|
<refpurpose>update rows of a table</refpurpose>
|
1999-07-14 22:32:59 +02:00
|
|
|
</refnamediv>
|
2003-04-27 01:56:51 +02:00
|
|
|
|
1999-07-14 22:32:59 +02:00
|
|
|
<refsynopsisdiv>
|
2003-04-27 01:56:51 +02:00
|
|
|
<synopsis>
|
2010-10-16 01:53:59 +02:00
|
|
|
[ WITH [ RECURSIVE ] <replaceable class="parameter">with_query</replaceable> [, ...] ]
|
2017-10-09 04:00:57 +02:00
|
|
|
UPDATE [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ] [ [ AS ] <replaceable class="parameter">alias</replaceable> ]
|
|
|
|
SET { <replaceable class="parameter">column_name</replaceable> = { <replaceable class="parameter">expression</replaceable> | DEFAULT } |
|
|
|
|
( <replaceable class="parameter">column_name</replaceable> [, ...] ) = [ ROW ] ( { <replaceable class="parameter">expression</replaceable> | DEFAULT } [, ...] ) |
|
|
|
|
( <replaceable class="parameter">column_name</replaceable> [, ...] ) = ( <replaceable class="parameter">sub-SELECT</replaceable> )
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
} [, ...]
|
2017-10-09 04:00:57 +02:00
|
|
|
[ FROM <replaceable class="parameter">from_list</replaceable> ]
|
|
|
|
[ WHERE <replaceable class="parameter">condition</replaceable> | WHERE CURRENT OF <replaceable class="parameter">cursor_name</replaceable> ]
|
2008-02-15 23:17:06 +01:00
|
|
|
[ RETURNING * | <replaceable class="parameter">output_expression</replaceable> [ [ AS ] <replaceable class="parameter">output_name</replaceable> ] [, ...] ]
|
2003-04-27 01:56:51 +02:00
|
|
|
</synopsis>
|
1999-07-14 22:32:59 +02:00
|
|
|
</refsynopsisdiv>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
1999-07-14 22:32:59 +02:00
|
|
|
|
|
|
|
<para>
|
2003-04-27 01:56:51 +02:00
|
|
|
<command>UPDATE</command> changes the values of the specified
|
|
|
|
columns in all rows that satisfy the condition. Only the columns to
|
2004-03-03 23:22:24 +01:00
|
|
|
be modified need be mentioned in the <literal>SET</literal> clause;
|
|
|
|
columns not explicitly modified retain their previous values.
|
1999-07-14 22:32:59 +02:00
|
|
|
</para>
|
|
|
|
|
2004-03-03 23:22:24 +01:00
|
|
|
<para>
|
|
|
|
There are two ways to modify a table using information contained in
|
|
|
|
other tables in the database: using sub-selects, or specifying
|
|
|
|
additional tables in the <literal>FROM</literal> clause. Which
|
|
|
|
technique is more appropriate depends on the specific
|
|
|
|
circumstances.
|
|
|
|
</para>
|
|
|
|
|
2006-08-12 04:52:06 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The optional <literal>RETURNING</literal> clause causes <command>UPDATE</command>
|
2006-08-12 04:52:06 +02:00
|
|
|
to compute and return value(s) based on each row actually updated.
|
|
|
|
Any expression using the table's columns, and/or columns of other
|
|
|
|
tables mentioned in <literal>FROM</literal>, can be computed.
|
|
|
|
The new (post-update) values of the table's columns are used.
|
2017-10-09 03:44:17 +02:00
|
|
|
The syntax of the <literal>RETURNING</literal> list is identical to that of the
|
|
|
|
output list of <command>SELECT</command>.
|
2006-08-12 04:52:06 +02:00
|
|
|
</para>
|
|
|
|
|
2000-06-09 03:44:34 +02:00
|
|
|
<para>
|
2009-01-22 21:16:10 +01:00
|
|
|
You must have the <literal>UPDATE</literal> privilege on the table,
|
|
|
|
or at least on the column(s) that are listed to be updated.
|
|
|
|
You must also have the <literal>SELECT</literal>
|
|
|
|
privilege on any column whose values are read in the
|
2006-01-22 21:34:11 +01:00
|
|
|
<replaceable class="parameter">expressions</replaceable> or
|
2003-07-03 18:34:26 +02:00
|
|
|
<replaceable class="parameter">condition</replaceable>.
|
2000-06-09 03:44:34 +02:00
|
|
|
</para>
|
1999-07-14 22:32:59 +02:00
|
|
|
</refsect1>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
<variablelist>
|
2010-10-16 01:53:59 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">with_query</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <literal>WITH</literal> clause allows you to specify one or more
|
2017-10-09 03:44:17 +02:00
|
|
|
subqueries that can be referenced by name in the <command>UPDATE</command>
|
2017-11-23 15:39:47 +01:00
|
|
|
query. See <xref linkend="queries-with"/> and <xref linkend="sql-select"/>
|
2010-10-16 01:53:59 +02:00
|
|
|
for details.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">table_name</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The name (optionally schema-qualified) of the table to update.
|
2017-10-09 03:44:17 +02:00
|
|
|
If <literal>ONLY</literal> is specified before the table name, matching rows
|
|
|
|
are updated in the named table only. If <literal>ONLY</literal> is not
|
2012-09-17 20:59:31 +02:00
|
|
|
specified, matching rows are also updated in any tables inheriting from
|
2017-10-09 03:44:17 +02:00
|
|
|
the named table. Optionally, <literal>*</literal> can be specified after the
|
2012-09-17 20:59:31 +02:00
|
|
|
table name to explicitly indicate that descendant tables are included.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2006-01-22 06:20:35 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable class="parameter">alias</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A substitute name for the target table. When an alias is
|
|
|
|
provided, it completely hides the actual name of the table. For
|
2017-10-09 03:44:17 +02:00
|
|
|
example, given <literal>UPDATE foo AS f</literal>, the remainder of the
|
2006-01-22 06:20:35 +01:00
|
|
|
<command>UPDATE</command> statement must refer to this table as
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>f</literal> not <literal>foo</literal>.
|
2006-01-22 06:20:35 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">column_name</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2012-06-22 00:06:14 +02:00
|
|
|
The name of a column in the table named by <replaceable
|
2017-10-09 04:00:57 +02:00
|
|
|
class="parameter">table_name</replaceable>.
|
2004-06-09 21:08:20 +02:00
|
|
|
The column name can be qualified with a subfield name or array
|
2006-01-22 21:34:11 +01:00
|
|
|
subscript, if needed. Do not include the table's name in the
|
|
|
|
specification of a target column — for example,
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>UPDATE table_name SET table_name.col = 1</literal> is invalid.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">expression</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
Update reference 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".
2007-02-01 00:26:05 +01:00
|
|
|
An expression to assign to the column. The expression can use the
|
2003-07-03 18:34:26 +02:00
|
|
|
old values of this and other columns in the table.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
2003-06-25 06:19:24 +02:00
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><literal>DEFAULT</literal></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-07-03 18:34:26 +02:00
|
|
|
Set the column to its default value (which will be NULL if no
|
|
|
|
specific default expression has been assigned to it).
|
2003-06-25 06:19:24 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
2003-04-27 01:56:51 +02:00
|
|
|
</varlistentry>
|
|
|
|
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">sub-SELECT</replaceable></term>
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
A <literal>SELECT</literal> sub-query that produces as many output columns
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
as are listed in the parenthesized column list preceding it. The
|
|
|
|
sub-query must yield no more than one row when executed. If it
|
|
|
|
yields one row, its column values are assigned to the target columns;
|
|
|
|
if it yields no rows, NULL values are assigned to the target columns.
|
|
|
|
The sub-query can refer to old values of the current row of the table
|
|
|
|
being updated.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">from_list</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A list of table expressions, allowing columns from other tables
|
2017-10-09 03:44:17 +02:00
|
|
|
to appear in the <literal>WHERE</literal> condition and the update
|
2004-03-03 23:22:24 +01:00
|
|
|
expressions. This is similar to the list of tables that can be
|
|
|
|
specified in the <xref linkend="sql-from"
|
2017-11-23 15:39:47 +01:00
|
|
|
endterm="sql-from-title"/> of a <command>SELECT</command>
|
2005-01-09 06:57:45 +01:00
|
|
|
statement. Note that the target table must not appear in the
|
2017-10-09 03:44:17 +02:00
|
|
|
<replaceable>from_list</replaceable>, unless you intend a self-join (in which
|
|
|
|
case it must appear with an alias in the <replaceable>from_list</replaceable>).
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">condition</replaceable></term>
|
2003-04-27 01:56:51 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2003-07-03 18:34:26 +02:00
|
|
|
An expression that returns a value of type <type>boolean</type>.
|
2017-10-09 03:44:17 +02:00
|
|
|
Only rows for which this expression returns <literal>true</literal>
|
2003-07-03 18:34:26 +02:00
|
|
|
will be updated.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2006-08-12 04:52:06 +02:00
|
|
|
|
2007-06-11 03:16:30 +02:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">cursor_name</replaceable></term>
|
2007-06-11 03:16:30 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The name of the cursor to use in a <literal>WHERE CURRENT OF</literal>
|
2007-06-11 03:16:30 +02:00
|
|
|
condition. The row to be updated is the one most recently fetched
|
2008-11-16 18:34:28 +01:00
|
|
|
from this cursor. The cursor must be a non-grouping
|
2017-10-09 03:44:17 +02:00
|
|
|
query on the <command>UPDATE</command>'s target table.
|
|
|
|
Note that <literal>WHERE CURRENT OF</literal> cannot be
|
2008-11-16 18:34:28 +01:00
|
|
|
specified together with a Boolean condition. See
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sql-declare"/>
|
2008-11-16 18:34:28 +01:00
|
|
|
for more information about using cursors with
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>WHERE CURRENT OF</literal>.
|
2007-06-11 03:16:30 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2006-08-12 04:52:06 +02:00
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">output_expression</replaceable></term>
|
2006-08-12 04:52:06 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
An expression to be computed and returned by the <command>UPDATE</command>
|
Update reference 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".
2007-02-01 00:26:05 +01:00
|
|
|
command after each row is updated. The expression can use any
|
2017-10-09 04:00:57 +02:00
|
|
|
column names of the table named by <replaceable class="parameter">table_name</replaceable>
|
2017-10-09 03:44:17 +02:00
|
|
|
or table(s) listed in <literal>FROM</literal>.
|
|
|
|
Write <literal>*</literal> to return all columns.
|
2006-08-12 04:52:06 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 04:00:57 +02:00
|
|
|
<term><replaceable class="parameter">output_name</replaceable></term>
|
2006-08-12 04:52:06 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
A name to use for a returned column.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2003-04-27 01:56:51 +02:00
|
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
2003-09-12 02:12:47 +02:00
|
|
|
<title>Outputs</title>
|
2003-04-27 01:56:51 +02:00
|
|
|
|
2003-09-12 02:12:47 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
On successful completion, an <command>UPDATE</command> command returns a command
|
2003-09-12 02:12:47 +02:00
|
|
|
tag of the form
|
|
|
|
<screen>
|
|
|
|
UPDATE <replaceable class="parameter">count</replaceable>
|
|
|
|
</screen>
|
|
|
|
The <replaceable class="parameter">count</replaceable> is the number
|
2011-10-10 18:53:04 +02:00
|
|
|
of rows updated, including matched rows whose values did not change.
|
|
|
|
Note that the number may be less than the number of rows that matched
|
|
|
|
the <replaceable class="parameter">condition</replaceable> when
|
2017-10-09 03:44:17 +02:00
|
|
|
updates were suppressed by a <literal>BEFORE UPDATE</literal> trigger. If
|
2011-10-10 18:53:04 +02:00
|
|
|
<replaceable class="parameter">count</replaceable> is 0, no rows were
|
|
|
|
updated by the query (this is not considered an error).
|
2003-09-12 02:12:47 +02:00
|
|
|
</para>
|
2006-08-12 04:52:06 +02:00
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
If the <command>UPDATE</command> command contains a <literal>RETURNING</literal>
|
|
|
|
clause, the result will be similar to that of a <command>SELECT</command>
|
2006-08-12 04:52:06 +02:00
|
|
|
statement containing the columns and values defined in the
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>RETURNING</literal> list, computed over the row(s) updated by the
|
2006-08-12 04:52:06 +02:00
|
|
|
command.
|
|
|
|
</para>
|
2003-04-27 01:56:51 +02:00
|
|
|
</refsect1>
|
|
|
|
|
2005-01-04 04:58:16 +01:00
|
|
|
<refsect1>
|
|
|
|
<title>Notes</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
When a <literal>FROM</literal> clause is present, what essentially happens
|
2005-01-09 06:57:45 +01:00
|
|
|
is that the target table is joined to the tables mentioned in the
|
2009-09-19 12:23:27 +02:00
|
|
|
<replaceable>from_list</replaceable>, and each output row of the join
|
2005-01-09 06:57:45 +01:00
|
|
|
represents an update operation for the target table. When using
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>FROM</literal> you should ensure that the join
|
2005-01-04 04:58:16 +01:00
|
|
|
produces at most one output row for each row to be modified. In
|
2005-01-09 06:57:45 +01:00
|
|
|
other words, a target row shouldn't join to more than one row from
|
2005-01-04 04:58:16 +01:00
|
|
|
the other table(s). If it does, then only one of the join rows
|
|
|
|
will be used to update the target row, but which one will be used
|
|
|
|
is not readily predictable.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2005-10-13 01:19:22 +02:00
|
|
|
Because of this indeterminacy, referencing other tables only within
|
2005-01-04 04:58:16 +01:00
|
|
|
sub-selects is safer, though often harder to read and slower than
|
|
|
|
using a join.
|
|
|
|
</para>
|
2016-12-13 14:18:00 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
In the case of a partitioned table, updating a row might cause it to no
|
Allow UPDATE to move rows between partitions.
When an UPDATE causes a row to no longer match the partition
constraint, try to move it to a different partition where it does
match the partition constraint. In essence, the UPDATE is split into
a DELETE from the old partition and an INSERT into the new one. This
can lead to surprising behavior in concurrency scenarios because
EvalPlanQual rechecks won't work as they normally did; the known
problems are documented. (There is a pending patch to improve the
situation further, but it needs more review.)
Amit Khandekar, reviewed and tested by Amit Langote, David Rowley,
Rajkumar Raghuwanshi, Dilip Kumar, Amul Sul, Thomas Munro, Álvaro
Herrera, Amit Kapila, and me. A few final revisions by me.
Discussion: http://postgr.es/m/CAJ3gD9do9o2ccQ7j7+tSgiE1REY65XRiMb=yJO3u3QhyP8EEPQ@mail.gmail.com
2018-01-19 21:33:06 +01:00
|
|
|
longer satisfy the partition constraint of the containing partition. In that
|
|
|
|
case, if there is some other partition in the partition tree for which this
|
|
|
|
row satisfies its partition constraint, then the row is moved to that
|
|
|
|
partition. If there is no such partition, an error will occur. Behind the
|
|
|
|
scenes, the row movement is actually a <command>DELETE</command> and
|
|
|
|
<command>INSERT</command> operation. However, there is a possibility that a
|
|
|
|
concurrent <command>UPDATE</command> or <command>DELETE</command> on the
|
|
|
|
same row may miss this row. For details see the section
|
|
|
|
<xref linkend="ddl-partitioning-declarative-limitations"/>.
|
2016-12-13 14:18:00 +01:00
|
|
|
</para>
|
2005-01-04 04:58:16 +01:00
|
|
|
</refsect1>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
1999-07-14 22:32:59 +02:00
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Change the word <literal>Drama</literal> to <literal>Dramatic</literal> in the
|
|
|
|
column <structfield>kind</structfield> of the table <structname>films</structname>:
|
1999-07-14 22:32:59 +02:00
|
|
|
|
2000-03-26 20:32:30 +02:00
|
|
|
<programlisting>
|
2003-07-03 18:34:26 +02:00
|
|
|
UPDATE films SET kind = 'Dramatic' WHERE kind = 'Drama';
|
2000-03-26 20:32:30 +02:00
|
|
|
</programlisting>
|
1999-07-14 22:32:59 +02:00
|
|
|
</para>
|
2003-07-03 18:34:26 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
Adjust temperature entries and reset precipitation to its default
|
2004-03-03 23:22:24 +01:00
|
|
|
value in one row of the table <structname>weather</structname>:
|
2003-07-03 18:34:26 +02:00
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT
|
|
|
|
WHERE city = 'San Francisco' AND date = '2003-07-03';
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
2006-08-12 04:52:06 +02:00
|
|
|
<para>
|
|
|
|
Perform the same operation and return the updated entries:
|
|
|
|
|
|
|
|
<programlisting>
|
|
|
|
UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT
|
|
|
|
WHERE city = 'San Francisco' AND date = '2003-07-03'
|
|
|
|
RETURNING temp_lo, temp_hi, prcp;
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
2006-09-04 00:37:06 +02:00
|
|
|
<para>
|
|
|
|
Use the alternative column-list syntax to do the same update:
|
|
|
|
<programlisting>
|
|
|
|
UPDATE weather SET (temp_lo, temp_hi, prcp) = (temp_lo+1, temp_lo+15, DEFAULT)
|
|
|
|
WHERE city = 'San Francisco' AND date = '2003-07-03';
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
2004-03-03 23:22:24 +01:00
|
|
|
<para>
|
|
|
|
Increment the sales count of the salesperson who manages the
|
|
|
|
account for Acme Corporation, using the <literal>FROM</literal>
|
|
|
|
clause syntax:
|
|
|
|
<programlisting>
|
|
|
|
UPDATE employees SET sales_count = sales_count + 1 FROM accounts
|
|
|
|
WHERE accounts.name = 'Acme Corporation'
|
|
|
|
AND employees.id = accounts.sales_person;
|
|
|
|
</programlisting>
|
2006-01-20 00:09:42 +01:00
|
|
|
</para>
|
2004-03-03 23:22:24 +01:00
|
|
|
|
2006-01-20 00:09:42 +01:00
|
|
|
<para>
|
2004-03-03 23:22:24 +01:00
|
|
|
Perform the same operation, using a sub-select in the
|
|
|
|
<literal>WHERE</literal> clause:
|
|
|
|
<programlisting>
|
|
|
|
UPDATE employees SET sales_count = sales_count + 1 WHERE id =
|
|
|
|
(SELECT sales_person FROM accounts WHERE name = 'Acme Corporation');
|
2004-08-08 03:48:31 +02:00
|
|
|
</programlisting>
|
2006-01-20 00:09:42 +01:00
|
|
|
</para>
|
2004-08-08 03:48:31 +02:00
|
|
|
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
<para>
|
|
|
|
Update contact names in an accounts table to match the currently assigned
|
|
|
|
salesmen:
|
|
|
|
<programlisting>
|
|
|
|
UPDATE accounts SET (contact_first_name, contact_last_name) =
|
|
|
|
(SELECT first_name, last_name FROM salesmen
|
|
|
|
WHERE salesmen.id = accounts.sales_id);
|
|
|
|
</programlisting>
|
|
|
|
A similar result could be accomplished with a join:
|
|
|
|
<programlisting>
|
|
|
|
UPDATE accounts SET contact_first_name = first_name,
|
|
|
|
contact_last_name = last_name
|
|
|
|
FROM salesmen WHERE salesmen.id = accounts.sales_id;
|
|
|
|
</programlisting>
|
|
|
|
However, the second query may give unexpected results
|
2017-10-09 03:44:17 +02:00
|
|
|
if <structname>salesmen</structname>.<structfield>id</structfield> is not a unique key, whereas
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
the first query is guaranteed to raise an error if there are multiple
|
2017-10-09 03:44:17 +02:00
|
|
|
<structfield>id</structfield> matches. Also, if there is no match for a particular
|
|
|
|
<structname>accounts</structname>.<structfield>sales_id</structfield> entry, the first query
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
will set the corresponding name fields to NULL, whereas the second query
|
|
|
|
will not update that row at all.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Update statistics in a summary table to match the current data:
|
|
|
|
<programlisting>
|
|
|
|
UPDATE summary s SET (sum_x, sum_y, avg_x, avg_y) =
|
|
|
|
(SELECT sum(x), sum(y), avg(x), avg(y) FROM data d
|
|
|
|
WHERE d.group_id = s.group_id);
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
2006-01-20 00:09:42 +01:00
|
|
|
<para>
|
2004-08-08 03:48:31 +02:00
|
|
|
Attempt to insert a new stock item along with the quantity of stock. If
|
2005-01-09 06:57:45 +01:00
|
|
|
the item already exists, instead update the stock count of the existing
|
2007-02-01 01:28:19 +01:00
|
|
|
item. To do this without failing the entire transaction, use savepoints:
|
2004-08-08 03:48:31 +02:00
|
|
|
<programlisting>
|
|
|
|
BEGIN;
|
2005-01-09 06:57:45 +01:00
|
|
|
-- other operations
|
2004-08-08 03:48:31 +02:00
|
|
|
SAVEPOINT sp1;
|
|
|
|
INSERT INTO wines VALUES('Chateau Lafite 2003', '24');
|
2005-01-09 06:57:45 +01:00
|
|
|
-- Assume the above fails because of a unique key violation,
|
|
|
|
-- so now we issue these commands:
|
2004-08-08 03:48:31 +02:00
|
|
|
ROLLBACK TO sp1;
|
2005-01-09 06:57:45 +01:00
|
|
|
UPDATE wines SET stock = stock + 24 WHERE winename = 'Chateau Lafite 2003';
|
|
|
|
-- continue with other operations, and eventually
|
2004-08-08 03:48:31 +02:00
|
|
|
COMMIT;
|
2004-03-03 23:22:24 +01:00
|
|
|
</programlisting>
|
|
|
|
</para>
|
2007-06-11 03:16:30 +02:00
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Change the <structfield>kind</structfield> column of the table
|
2007-06-11 03:16:30 +02:00
|
|
|
<structname>films</structname> in the row on which the cursor
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>c_films</literal> is currently positioned:
|
2007-06-11 03:16:30 +02:00
|
|
|
<programlisting>
|
|
|
|
UPDATE films SET kind = 'Dramatic' WHERE CURRENT OF c_films;
|
2011-08-07 09:49:45 +02:00
|
|
|
</programlisting></para>
|
1999-07-14 22:32:59 +02:00
|
|
|
</refsect1>
|
|
|
|
|
2003-04-27 01:56:51 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Compatibility</title>
|
|
|
|
|
|
|
|
<para>
|
2005-01-09 06:57:45 +01:00
|
|
|
This command conforms to the <acronym>SQL</acronym> standard, except
|
2017-10-09 03:44:17 +02:00
|
|
|
that the <literal>FROM</literal> and <literal>RETURNING</literal> clauses
|
2010-10-16 01:53:59 +02:00
|
|
|
are <productname>PostgreSQL</productname> extensions, as is the ability
|
2017-10-09 03:44:17 +02:00
|
|
|
to use <literal>WITH</literal> with <command>UPDATE</command>.
|
2003-04-27 01:56:51 +02:00
|
|
|
</para>
|
2005-01-09 06:57:45 +01:00
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Some other database systems offer a <literal>FROM</literal> option in which
|
|
|
|
the target table is supposed to be listed again within <literal>FROM</literal>.
|
2005-01-09 06:57:45 +01:00
|
|
|
That is not how <productname>PostgreSQL</productname> interprets
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>FROM</literal>. Be careful when porting applications that use this
|
2005-01-09 06:57:45 +01:00
|
|
|
extension.
|
|
|
|
</para>
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
According to the standard, the source value for a parenthesized sub-list of
|
Improve handling of "UPDATE ... SET (column_list) = row_constructor".
Previously, the right-hand side of a multiple-column assignment, if it
wasn't a sub-SELECT, had to be a simple parenthesized expression list,
because gram.y was responsible for "bursting" the construct into
independent column assignments. This had the minor defect that you
couldn't write ROW (though you should be able to, since the standard says
this is a row constructor), and the rather larger defect that unlike other
uses of row constructors, we would not expand a "foo.*" item into multiple
columns.
Fix that by changing the RHS to be just "a_expr" in the grammar, leaving
it to transformMultiAssignRef to separate the elements of a RowExpr;
which it will do only after performing standard transformation of the
RowExpr, so that "foo.*" behaves as expected.
The key reason we didn't do that before was the hard-wired handling of
DEFAULT tokens (SetToDefault nodes). This patch deals with that issue by
allowing DEFAULT in any a_expr and having parse analysis throw an error
if SetToDefault is found in an unexpected place. That's an improvement
anyway since the error can be more specific than just "syntax error".
The SQL standard suggests that the RHS could be any a_expr yielding a
suitable row value. This patch doesn't really move the goal posts in that
respect --- you're still limited to RowExpr or a sub-SELECT --- but it does
fix the grammar restriction, so it provides some tangible progress towards
a full implementation. And the limitation is now documented by an explicit
error message rather than an unhelpful "syntax error".
Discussion: <8542.1479742008@sss.pgh.pa.us>
2016-11-22 21:19:57 +01:00
|
|
|
target column names can be any row-valued expression yielding the correct
|
|
|
|
number of columns. <productname>PostgreSQL</productname> only allows the
|
|
|
|
source value to be a <link linkend="sql-syntax-row-constructors">row
|
2017-10-09 03:44:17 +02:00
|
|
|
constructor</link> or a sub-<literal>SELECT</literal>. An individual column's
|
|
|
|
updated value can be specified as <literal>DEFAULT</literal> in the
|
|
|
|
row-constructor case, but not inside a sub-<literal>SELECT</literal>.
|
Implement UPDATE tab SET (col1,col2,...) = (SELECT ...), ...
This SQL-standard feature allows a sub-SELECT yielding multiple columns
(but only one row) to be used to compute the new values of several columns
to be updated. While the same results can be had with an independent
sub-SELECT per column, such a workaround can require a great deal of
duplicated computation.
The standard actually says that the source for a multi-column assignment
could be any row-valued expression. The implementation used here is
tightly tied to our existing sub-SELECT support and can't handle other
cases; the Bison grammar would have some issues with them too. However,
I don't feel too bad about this since other cases can be converted into
sub-SELECTs. For instance, "SET (a,b,c) = row_valued_function(x)" could
be written "SET (a,b,c) = (SELECT * FROM row_valued_function(x))".
2014-06-18 19:22:25 +02:00
|
|
|
</para>
|
1999-07-14 22:32:59 +02:00
|
|
|
</refsect1>
|
|
|
|
</refentry>
|