- The executor mechanism is used to evaluate all four basic SQL query
+ The executor mechanism is used to evaluate all five basic SQL query
types: SELECT, INSERT,
- UPDATE, and DELETE.
+ UPDATE, DELETE, and
+ MERGE.
For SELECT, the top-level executor code
only needs to send each row returned by the query plan tree
off to the client. INSERT ... SELECT,
- UPDATE, and DELETE
+ UPDATE, DELETE, and
+ MERGE
are effectively SELECTs under a special
top-level plan node called ModifyTable.
mark the old row deleted. For DELETE, the only
column that is actually returned by the plan is the TID, and the
ModifyTable node simply uses the TID to visit each
- target row and mark it deleted.
+ target row and mark it deleted. For MERGE, the
+ planner joins the source and target relations, and includes all
+ column values required by any of the WHEN clauses,
+ plus the TID of the target row; this data is fed up to the
+ ModifyTable node, which uses the information to
+ work out which WHEN clause to execute, and then
+ inserts, updates or deletes the target row, as required.
view, or other table-like object.
Also allows use of COPY TO.
This privilege is also needed to reference existing column values in
- UPDATE or DELETE.
+ UPDATE, DELETE,
+ or MERGE.
For sequences, this privilege also allows use of the
currval function.
For large objects, this privilege allows the object to be read.
Data Manipulation Language (DML): INSERT,
- UPDATE, DELETE, COPY FROM,
+ UPDATE, DELETE,
+ MERGE, COPY FROM,
TRUNCATE.
Note that there are no allowed actions that result in a trigger
being executed during recovery. This restriction applies even to
As seen in this example, when the query is an INSERT,
- UPDATE, or DELETE command, the actual work of
+ UPDATE, DELETE, or
+ MERGE command, the actual work of
applying the table changes is done by a top-level Insert, Update,
- or Delete plan node. The plan nodes underneath this node perform
+ Delete, or Merge plan node. The plan nodes underneath this node perform
the work of locating the old rows and/or computing the new data.
So above, we see the same sort of bitmap table scan we've seen already,
and its output is fed to an Update node that stores the updated rows.
- When an UPDATE or DELETE command affects an
+ When an UPDATE, DELETE, or
+ MERGE command affects an
inheritance hierarchy, the output might look like this:
PL/pgSQL variable values can be
automatically inserted into optimizable SQL commands, which
are SELECT, INSERT,
- UPDATE, DELETE, and certain
+ UPDATE, DELETE,
+ MERGE, and certain
utility commands that incorporate one of these, such
as EXPLAIN and CREATE TABLE ... AS
SELECT. In these commands,
rows is the number of rows updated.
+ For a MERGE command, the tag is
+ MERGE rows where
+ rows is the number of rows inserted,
+ updated, or deleted.
+
+
For a SELECT or CREATE TABLE AS
command, the tag is SELECT rows
in a WITH clause can be a SELECT,
INSERT, UPDATE, or DELETE; and the
WITH clause itself is attached to a primary statement that can
- also be a SELECT, INSERT, UPDATE, or
- DELETE.
+ be a SELECT, INSERT, UPDATE,
+ DELETE, or MERGE.
The examples above only show WITH being used with
SELECT, but it can be attached in the same way to
- INSERT, UPDATE, or DELETE.
+ INSERT, UPDATE,
+ DELETE, or MERGE.
In each case it effectively provides temporary table(s) that can
be referred to in the main command.
Data-Modifying Statements in <literal>WITH</literal>
- You can use data-modifying statements (INSERT,
- UPDATE, or DELETE) in WITH. This
+ You can use most data-modifying statements (INSERT,
+ UPDATE, or DELETE, but not
+ MERGE) in WITH. This
allows you to perform several different operations in the same query.
An example is:
UPDATE, or it may not be published at all.
+ For a MERGE command, the publication will publish an
+ INSERT, UPDATE, or DELETE
+ for each row inserted, updated, or deleted.
+
+
ATTACHing a table into a partition tree whose root is
published using a publication with publish_via_partition_root
statement will happen as usual. If you wish to use
EXPLAIN ANALYZE on an
INSERT, UPDATE,
- DELETE, CREATE TABLE AS,
+ DELETE, MERGE,
+ CREATE TABLE AS,
or EXECUTE statement
without letting the command affect your data, use this approach:
Any SELECT, INSERT, UPDATE,
- DELETE, VALUES, EXECUTE,
+ DELETE, MERGE,
+ VALUES, EXECUTE,
DECLARE, CREATE TABLE AS, or
CREATE MATERIALIZED VIEW AS statement, whose execution
plan you wish to see.
Any SELECT, INSERT, UPDATE,
- DELETE, or VALUES statement.
+ DELETE, MERGE, or VALUES
+ statement.
The transaction isolation level cannot be changed after the first query or
data-modification statement (SELECT,
INSERT, DELETE,
- UPDATE, FETCH, or
+ UPDATE, MERGE,
+ FETCH, or
COPY) of a transaction has been executed. See
for more information about transaction
isolation and concurrency control.
The transaction access mode determines whether the transaction is
read/write or read-only. Read/write is the default. When a
transaction is read-only, the following SQL commands are
- disallowed: INSERT, UPDATE,
- DELETE, and COPY FROM if the
+ disallowed: INSERT, UPDATE,
+ DELETE, MERGE, and
+ COPY FROM if the
table they would write to is not a temporary table; all
CREATE, ALTER, and
DROP commands; COMMENT,
start of a transaction, before the first query or
data-modification statement (SELECT,
INSERT, DELETE,
- UPDATE, FETCH, or
+ UPDATE, MERGE,
+ FETCH, or
COPY) of the transaction. Furthermore, the transaction
must already be set to SERIALIZABLE or
REPEATABLE READ isolation level (otherwise, the snapshot
language can be packaged together and defined as a function.
Besides SELECT queries, the commands can include data
modification queries (INSERT,
- UPDATE, and DELETE), as well as
+ UPDATE, DELETE, and
+ MERGE), as well as
other SQL commands. (You cannot use transaction control commands, e.g.,
COMMIT, SAVEPOINT, and some utility
commands, e.g.,
VACUUM, in
SQL functions.)
projects / postgresql.git / commitdiff