Re: problem with RETURNING and update row movement

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: problem with RETURNING and update row movement
Дата
Msg-id CAPmGK14QXD5Te_vwGgpuVWXRcrC+d8FyWse0aHSqnDDSeeCRFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: problem with RETURNING and update row movement  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Ответы Re: problem with RETURNING and update row movement  (Amit Langote <amitlangote09@gmail.com>)
Re: problem with RETURNING and update row movement  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Yet another thing I noticed is that the patch incorrectly produces
values for the tableoid columns specified in the RETURNING list, like
this:

+UPDATE range_parted r set a = 'c' FROM (VALUES ('a', 1), ('a', 10),
('b', 12)) s(x, y) WHERE s.x = r.a AND s.y = r.b RETURNING
tableoid::regclass, *;
+    tableoid    | a | b  |  c  | d |       e       | x | y
+----------------+---+----+-----+---+---------------+---+----
+ part_a_1_a_10  | c |  1 |   1 | 1 | in trigfunc() | a |  1
+ part_a_10_a_20 | c | 10 | 200 | 1 | in trigfunc() | a | 10
+ part_c_1_100   | c | 12 |  96 | 1 | in trigfunc() | b | 12
+(3 rows)

The source partitions are shown as tableoid, but the destination
partition (ie, part_c_1_c_20) should be shown.  To fix this, I
modified the patch further so that 1) we override tts_tableOid of the
original slot with the OID of the destination partition before calling
ExecProcessReturning() if needed, and 2) in ExecProcessReturning(), we
only initialize ecxt_scantuple's tts_tableOid when needed, which would
save cycles a bit for non-foreign-table-direct-modification cases.

Attached is a new version of the patch.

Best regards,
Etsuro Fujita

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: OpenSSL randomness seeding
Следующее
От: Andy Fan
Дата:
Сообщение: Re: Index Skip Scan (new UniqueKeys)