説明

<command>UPDATE</command> changes the values of the specified columns in all rows that satisfy the condition. Only the columns to be modified need be mentioned in the <literal>SET</literal> clause; columns not explicitly modified retain their previous values. UPDATEは、条件を満たす全ての行の指定した列の値を変更します。 SET句には、変更する列のみを指定する必要があります。 SET句にて明示的に指定されなかった列の値は変更されません。

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. データベース内の他のテーブルの情報を使用してテーブルを変更するには、2つの方法があります。 1つは副SELECTを使用する方法、もう1つはFROM句で追加のテーブルを指定する方法です。 どちらの方法が適切であるかは状況次第です。

The optional <literal>RETURNING</literal> clause causes <command>UPDATE</command> 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. The syntax of the <literal>RETURNING</literal> list is identical to that of the output list of <command>SELECT</command>. RETURNING句を指定すると、UPDATEは実際に更新された各行に基づいて計算された値を返すようになります。 そのテーブルの列およびFROMで指定された他のテーブルの列を使用した式を計算することができます。 テーブル列の新しい（更新された後の）値が使用されます。 RETURNINGリストの構文はSELECTの出力リストと同一です。

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 <replaceable class="parameter">expressions</replaceable> or <replaceable class="parameter">condition</replaceable>. 更新を行うためには、そのテーブルまたは少なくとも更新対象の列についてUPDATE権限を持たなければなりません。 またexpressionsやconditionで値を読み込む列に対するSELECT権限も必要になります。

パラメータ

出力

On successful completion, an <command>UPDATE</command> command returns a command tag of the form 正常に処理が終わると、UPDATEコマンドは以下の形式のコマンドタグを返します。

UPDATE count

The <replaceable class="parameter">count</replaceable> is the number 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 updates were suppressed by a <literal>BEFORE UPDATE</literal> trigger. If <replaceable class="parameter">count</replaceable> is 0, no rows were updated by the query (this is not considered an error). countは、合致したが変更されなかった行を含む、更新された行数です。 この数は、BEFORE UPDATEトリガにより更新が抑止された場合、conditionに合致した行より少なくなる可能性があることに注意してください。 countが0の場合、問い合わせによって更新された行がなかったことを示します （これはエラーとはみなされません）。

If the <command>UPDATE</command> command contains a <literal>RETURNING</literal> clause, the result will be similar to that of a <command>SELECT</command> statement containing the columns and values defined in the <literal>RETURNING</literal> list, computed over the row(s) updated by the command. UPDATEコマンドがRETURNING句を持つ場合、その結果は、RETURNINGリストで定義した列と値を持ち、そのコマンドで更新された行全体に対して計算を行うSELECT文の結果と似たものになるでしょう。

注釈

When a <literal>FROM</literal> clause is present, what essentially happens is that the target table is joined to the tables mentioned in the <replaceable>from_item</replaceable> list, and each output row of the join represents an update operation for the target table. When using <literal>FROM</literal> you should ensure that the join produces at most one output row for each row to be modified. In other words, a target row shouldn't join to more than one row from 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. FROM句が存在する場合、基本的に、対象テーブルとfrom_itemリストで指定されたテーブルが結合され、この結合の出力行が対象テーブルの更新操作の結果となります。 FROM句を使用する場合、更新対象テーブルの1行に対して、結合結果が複数行にならないように注意してください。 言い換えると、対象テーブルの個々の行は、他テーブルの複数の行と結合すべきではありません。 結合結果が複数行になった場合、対象行の更新には結合結果のいずれか1行のみが使用されますが、どの行が使用されるかは簡単には予測できません。

Because of this indeterminacy, referencing other tables only within sub-selects is safer, though often harder to read and slower than using a join. このような不定性の問題があるため、他テーブルの参照は副SELECT内のみに留めておいた方がより安全です（ただし、結合よりも可読性や実行速度は低下します）。

In the case of a partitioned table, updating a row might cause it to no 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. パーティションテーブルの場合、行を更新することによって含んでいるパーティションのパーティション制約を満たさなくなることがありえます。 その場合、この行がそのパーティション制約を満たす他のパーティションがパーティションツリー内にあれば、行はそのパーティションに移されます。 もし、そのようなパーティションがなければ、エラーが発生します。 舞台裏では、行の移動は実際はDELETEとINSERT操作です。

There is a possibility that a concurrent <command>UPDATE</command> or <command>DELETE</command> on the row being moved will get a serialization failure error. Suppose session 1 is performing an <command>UPDATE</command> on a partition key, and meanwhile a concurrent session 2 for which this row is visible performs an <command>UPDATE</command> or <command>DELETE</command> operation on this row. In such case, session 2's <command>UPDATE</command> or <command>DELETE</command> will detect the row movement and raise a serialization failure error (which always returns with an SQLSTATE code '40001'). Applications may wish to retry the transaction if this occurs. In the usual case where the table is not partitioned, or where there is no row movement, session 2 would have identified the newly updated row and carried out the <command>UPDATE</command>/<command>DELETE</command> on this new row version. 移される行に対して同時に実行されるUPDATEやDELETEのために直列化の失敗エラーになる可能性があります。 セッション1がパーティションキーに対してUPDATEを実行中であるとしましょう。一方、同時に実行しているセッション2に対してこの行は可視であり、セッション2はこの行に対してUPDATEまたはDELETE操作をするとしましょう。 その場合、セッション2のUPDATEまたはDELETEは、行の移動を検出し、直列化の失敗エラー(常にSQLSTATE値が'40001'で返る)を発生させます。 これが起きた場合には、アプリケーションはトランザクションを再試行すると良いでしょう。 テーブルがパーティション化されていない、または、行の移動がない通常の場合には、セッション2は新しく更新された行を特定し、この新しい行のバージョンに対してUPDATE/DELETEを実行します。

Note that while rows can be moved from local partitions to a foreign-table partition (provided the foreign data wrapper supports tuple routing), they cannot be moved from a foreign-table partition to another partition. (外部データラッパーがタプルルーティングをサポートしていれば)行をローカルパーティションから外部テーブルパーティションへ移動できますが、外部テーブルパーティションから別のパーティションに移動できないことに注意してください。

An attempt of moving a row from one partition to another will fail if a foreign key is found to directly reference an ancestor of the source partition that is not the same as the ancestor that's mentioned in the <command>UPDATE</command> query. あるパーティションから別のパーティションへ行を移動しようとしても、UPDATE問い合わせで指定された祖先とは異なる移動元のパーティションの祖先を外部キーが直接参照していることが判明した場合、失敗します。

例

Change the word <literal>Drama</literal> to <literal>Dramatic</literal> in the column <structfield>kind</structfield> of the table <structname>films</structname>: filmsテーブルのkind列にあるDramaという単語をDramaticに変更します。

UPDATE films SET kind = 'Dramatic' WHERE kind = 'Drama';

Adjust temperature entries and reset precipitation to its default value in one row of the table <structname>weather</structname>: weatherテーブルの特定の行に対し、気温に関する項目を調整し、降水量をデフォルト値に戻します。

UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT
  WHERE city = 'San Francisco' AND date = '2003-07-03';

Perform the same operation and return the updated entries: 同じ操作を行い、更新された項目を返します。

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;

Use the alternative column-list syntax to do the same update: もう一つの方法である列リスト構文を使用して同じ更新を行います。

UPDATE weather SET (temp_lo, temp_hi, prcp) = (temp_lo+1, temp_lo+15, DEFAULT)
  WHERE city = 'San Francisco' AND date = '2003-07-03';

Increment the sales count of the salesperson who manages the account for Acme Corporation, using the <literal>FROM</literal> clause syntax: FROM句の構文を使用して、Acme Corporationを顧客とするセールスパーソンのセールスカウントを1増加させます。

UPDATE employees SET sales_count = sales_count + 1 FROM accounts
  WHERE accounts.name = 'Acme Corporation'
  AND employees.id = accounts.sales_person;

Perform the same operation, using a sub-select in the <literal>WHERE</literal> clause: WHERE句で副SELECTを使用して、同じ操作を行います。

UPDATE employees SET sales_count = sales_count + 1 WHERE id =
  (SELECT sales_person FROM accounts WHERE name = 'Acme Corporation');

Update contact names in an accounts table to match the currently assigned salespeople: accountsテーブルのコンタクト先の氏名を、現在アサインされているセールスパーソンと一致するよう更新します。

UPDATE accounts SET (contact_first_name, contact_last_name) =
    (SELECT first_name, last_name FROM employees
     WHERE employees.id = accounts.sales_person);

A similar result could be accomplished with a join: 同じような結果は結合を使っても得ることができます。

UPDATE accounts SET contact_first_name = first_name,
                    contact_last_name = last_name
  FROM employees WHERE employees.id = accounts.sales_person;

However, the second query may give unexpected results if <structname>employees</structname>.<structfield>id</structfield> is not a unique key, whereas the first query is guaranteed to raise an error if there are multiple <structfield>id</structfield> matches. Also, if there is no match for a particular <structname>accounts</structname>.<structfield>sales_person</structfield> entry, the first query will set the corresponding name fields to NULL, whereas the second query will not update that row at all. ただし、employees.idが一意キーでない場合、2番目の問い合わせは予期しない結果をもたらすかもしれません。 一方で、最初の問い合わせは、複数のidがマッチしたときはエラーを発生することが保証されます。 また、あるaccounts.sales_personエントリにマッチするレコードがない場合、最初の問い合わせは対応する名前フィールドをNULLに設定しますが、2番目の問い合わせは、その行を全く更新しません。

Update statistics in a summary table to match the current data: summaryテーブルの統計情報を現在のデータに合うように更新します。

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);

Attempt to insert a new stock item along with the quantity of stock. If the item already exists, instead update the stock count of the existing item. To do this without failing the entire transaction, use savepoints: 新しい商品とその在庫数を挿入します。 既にその商品が存在している場合は、代わりに既存商品の在庫数を更新します。 トランザクション全体が失敗することがないようにこの操作を行うには、セーブポイントを使用してください。

BEGIN;

-- other operations

-- 何かしらの他の操作を行います。
SAVEPOINT sp1;
INSERT INTO wines VALUES('Chateau Lafite 2003', '24');

-- Assume the above fails because of a unique key violation,
-- so now we issue these commands:

-- 上記のコマンドが一意キー違反により失敗したとします。
-- この場合、次のコマンドを実行します。
ROLLBACK TO sp1;
UPDATE wines SET stock = stock + 24 WHERE winename = 'Chateau Lafite 2003';

-- continue with other operations, and eventually

-- 他の操作を続けた後、最後に次を実行します。
COMMIT;

Change the <structfield>kind</structfield> column of the table <structname>films</structname> in the row on which the cursor <literal>c_films</literal> is currently positioned: filmsテーブルにおいて、c_filmsカーソルが現在位置している行のkind列を変更します。

UPDATE films SET kind = 'Dramatic' WHERE CURRENT OF c_films;

Updates affecting many rows can have negative effects on system performance, such as table bloat, increased replica lag, and increased lock contention. In such situations it can make sense to perform the operation in smaller batches, possibly with a <command>VACUUM</command> operation on the table between batches. While there is no <literal>LIMIT</literal> clause for <command>UPDATE</command>, it is possible to get a similar effect through the use of a <link linkend="queries-with">Common Table Expression</link> and a self-join. With the standard <productname>PostgreSQL</productname> table access method, a self-join on the system column <link linkend="ddl-system-columns-ctid">ctid</link> is very efficient: 《機械翻訳》多数の行に影響する更新は、テーブルの肥大化、レプリカの遅延の増加、ロック競合の増加など、システムパフォーマンスに悪影響を及ぼす可能性があります。 このような状況では、バッチ間でテーブルに対してVACUUM操作を行うことで、より小さなバッチで操作を実行することが理にかなっています。 UPDATEにはLIMIT句はありませんが、共通テーブル式と自己結合を使用することで同様の効果を得ることができます。 標準のPostgreSQLテーブルアクセスメソッドでは、システム列ctidに対する自己結合は非常に効率的です。

WITH exceeded_max_retries AS (
  SELECT w.ctid FROM work_item AS w
    WHERE w.status = 'active' AND w.num_retries > 10
    ORDER BY w.retry_timestamp
    FOR UPDATE
    LIMIT 5000
)
UPDATE work_item SET status = 'failed'
  FROM exceeded_max_retries AS emr
  WHERE work_item.ctid = emr.ctid;

This command will need to be repeated until no rows remain to be updated. Use of an <literal>ORDER BY</literal> clause allows the command to prioritize which rows will be updated; it can also prevent deadlock with other update operations if they use the same ordering. If lock contention is a concern, then <literal>SKIP LOCKED</literal> can be added to the <acronym>CTE</acronym> to prevent multiple commands from updating the same row. However, then a final <command>UPDATE</command> without <literal>SKIP LOCKED</literal> or <literal>LIMIT</literal> will be needed to ensure that no matching rows were overlooked. 《機械翻訳》更新する行がなくなるまで、このコマンドを繰り返す必要があります。 ORDER BY句を使用すると、コマンドは更新する行を優先順位付けできます。 また、他の更新操作が同じ順序を使用する場合、それらによるデッドロックを防ぐことができます。 ロック競合が懸念される場合、CTEにSKIP LOCKEDを追加して、複数のコマンドが同じ行を更新するのを防ぐことができます。 しかし、一致する行が見落とされないようにするためには、SKIP LOCKEDまたはLIMITを指定しない最後のUPDATEが必要です。

互換性

This command conforms to the <acronym>SQL</acronym> standard, except that the <literal>FROM</literal> and <literal>RETURNING</literal> clauses are <productname>PostgreSQL</productname> extensions, as is the ability to use <literal>WITH</literal> with <command>UPDATE</command>. このコマンドは標準SQLに準拠しています。 ただしFROM句およびRETURNING句はPostgreSQLの拡張です。 UPDATEでWITHが使用可能であることも同様に拡張です。

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>. That is not how <productname>PostgreSQL</productname> interprets <literal>FROM</literal>. Be careful when porting applications that use this extension. 他のデータベースシステムには、FROMオプション内で、対象テーブルがFROM内に再度指定されることを前提として動作するものもあります。 これはPostgreSQLにおけるFROMの解釈方法とは異なります。 この拡張機能を使用するアプリケーションを移植する時は注意してください。

According to the standard, the source value for a parenthesized sub-list of 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 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>. 標準に従うと、括弧内の対象列名の部分リストに対する入力値は、正しい数の列を生成する任意の行値による式です。 PostgreSQLでは入力値として、行コンストラクタあるいはsub-SELECTしか許していません。 行コンストラクタを使う場合、個々の列の更新値をDEFAULTとして指定することができますが、sub-SELECTの内部ではできません。