diff options
| author | Dean Rasheed <dean.a.rasheed@gmail.com> | 2023-11-09 11:23:42 +0000 |
|---|---|---|
| committer | Dean Rasheed <dean.a.rasheed@gmail.com> | 2023-11-09 11:23:42 +0000 |
| commit | a4f7d33a904fcd4da7a12d249416dd2c5c5f2c1c (patch) | |
| tree | d785f549246266bf11447f38145b9530df966383 /src/backend/utils/adt/arrayutils.c | |
| parent | 10d34fefc2ab3c12b03772744c24000c44b7a550 (diff) | |
| download | postgresql-a4f7d33a904fcd4da7a12d249416dd2c5c5f2c1c.tar.gz postgresql-a4f7d33a904fcd4da7a12d249416dd2c5c5f2c1c.zip | |
Fix AFTER ROW trigger execution in MERGE cross-partition update.
When executing a MERGE UPDATE action, if the UPDATE is turned into a
cross-partition DELETE then INSERT, do not attempt to invoke AFTER
UPDATE ROW triggers, or any of the other post-update actions in
ExecUpdateEpilogue().
For consistency with a plain UPDATE command, such triggers should not
be fired (and typically fail anyway), and similarly, other post-update
actions, such as WCO/RLS checks should not be executed, and might also
lead to unexpected failures.
Therefore, as with ExecUpdate(), make ExecMergeMatched() return
immediately if ExecUpdateAct() reports that a cross-partition update
was done, to be sure that no further processing is done for that
tuple.
Back-patch to v15, where MERGE was introduced.
Discussion: https://postgr.es/m/CAEZATCWjBgagyNZs02vgDF0DvASYj-iHTFtXG2-nP3orZhmtcw%40mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/arrayutils.c')
0 files changed, 0 insertions, 0 deletions