Re: 'update returning *' returns 0 columns instead of empty row with2 columns when (i) no rows updated and (ii) when applied to a partitionedtable with sub-partition - Mailing list pgsql-bugs

From Amit Langote
Subject Re: 'update returning *' returns 0 columns instead of empty row with2 columns when (i) no rows updated and (ii) when applied to a partitionedtable with sub-partition
Date
Msg-id c3b4762b-ccb4-8e6d-7012-e2c7ea76bc01@lab.ntt.co.jp
Whole thread Raw
In response to 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  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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
List pgsql-bugs
On 2019/02/22 13:43, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
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
Next
From: PG Bug reporting form
Date:
Subject: BUG #15649: ERROR: terminating connection due to administrator command