Teradata Parallel Data Pump

Chapter 3: Teradata TPump Commands
UPDATE Statement and Atomic Upsert
used in other ways with Atomic upsert statements. For example, a DECLARE CURSOR
statement may include upsert statements among those to be executed when the cursor is
opened, as long as the upserts are otherwise valid.
• UPDATE-FROM: Not supported. The SET clause cannot use a FROM clause table
reference in the expression for the updated value for a column.
• UPDATE-WHERE SUBQUERIES: Not supported. The WHERE clause cannot use a
subquery either to specify the primary index or to constrain a nonindex column. Note that
supporting this UPDATE syntax would also require support for either INSERT … SELECT
or some other INSERT syntax feature that lets it specify the same primary index value as
the UPDATE.
• UPDATE-PRIMARY INDEX: Not supported. The UPDATE cannot change the primary
index. This is sometime called unreasonable update.
• TRIGGERS: Feature not supported if either the UPDATE or INSERT could cause a trigger
to be fired. The restriction applies as if the UPDATE and INSERT were both executed,
because the parser trigger logic will not attempt to account for their conditional execution.
UPDATE triggers on columns not referenced by the UPDATE clause, however, will never
be fired by the upsert and are therefore permitted. DELETE triggers cannot be fired at all
by an upsert and are likewise permitted. Note that an upsert could be used as a trigger
action but it would be subject to the same constraints as any other upsert. Because upsert
is not allowed to fire any triggers itself, an upsert trigger action must not generate any
further cascaded trigger actions.
• JOIN/HASH INDEXES: Feature not supported if either the UPDATE or INSERT could
cause the join/hash index to be updated. As with triggers, the restriction applies to each
upsert as if the UPDATE and INSERT were both executed. While the UPDATE could
escape this restriction if the join/hash index does not reference any of the updated
columns, it is much less likely (and maybe impossible) for the INSERT to escape this
restriction. If the benefit of lifting the restriction for a few unlikely join/hash index cases
turns out to be not worth the implementation cost, the restriction may have to be applied
more broadly to any table with an associated join/hash index.
Teradata TPump treats a failed constraint as a nonfatal error, reports the error in the job log
for diagnostic purposes, and continues with the job by reverting to nonbasic upsert protocol.
To resolve order-dependency issues, Teradata TPump always processes the UPDATE before the
INSERT because:
• It matches the ordering implied by the upsert name: UP[date] + [in]SERT.
• It matches the ordering implied by the UPDATE-ELSE-INSERT syntax.
• It matches the common definition of upsert semantics.
• It allows for an upsert operation on MULTISET tables, where an insert-first policy would
always succeed on INSERT and never on UPDATE.
Existing Teradata TPump scripts for upsert do not need to be changed. The syntax as
described below for upsert will continue to be supported:
DO INSERT FOR MISSING UPDATE ROWS;
UPDATE ;
INSERT ;
Teradata Parallel Data Pump Reference 191