Re: 'update returning *' returns 0 columns instead of empty row with 2 columns when (i) no rows updated and (ii) when applied to a partitioned table with sub-partition

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: 'update returning *' returns 0 columns instead of empty row with 2 columns when (i) no rows updated and (ii) when applied to a partitioned table with sub-partition
Date: 2019-02-22 05:33:55
Message-ID: c3b4762b-ccb4-8e6d-7012-e2c7ea76bc01@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs

On 2019/02/22 13:43, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> Also, I noticed regression test failure having to do with statement
>> triggers not firing, which makes sense, as there's no ModifyTable to
>> invoke them.
>
> Oh! You are right, that's a separate bug. So really we can't have
> this fast-path exit at all, we should produce a ModifyTable node in
> every case.
>
> I'm too tired to work on that anymore today, do you want to run
> with it?

Sure, see attached a patch.

To fix the trigger bug, we'll be putting a minimally valid-looking
ModifyTable node on top of a dummy plan. So, the bug reported on this
thread is taken care of automatically, because ModifyTable plan's
targetlist is already set correctly.

Thanks,
Amit

Attachment Content-Type Size
fix-empty-plan-with-RETURNING-3.patch text/plain 6.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-02-22 08:06:42 BUG #15649: ERROR: terminating connection due to administrator command
Previous Message Tom Lane 2019-02-22 04:43:13 Re: 'update returning *' returns 0 columns instead of empty row with 2 columns when (i) no rows updated and (ii) when applied to a partitioned table with sub-partition