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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
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-21 22:18:10
Message-ID: 13543.1550787490@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> On 2019/02/01 23:32, Petr Fedorov wrote:
>> ERROR: structure of query does not match function result type

> Thanks for the report. There indeed appears to be a bug here.

Yup, for sure. You don't actually need a function at all to see
that there's a problem: if you just execute
UPDATE ... WHERE false RETURNING some-columns;
you will notice that the emitted resultset has zero columns.

> Attached patch seems to fix it. It also adds a test in inherit.sql.

This isn't quite right, because what we actually need to return is the
RETURNING column set. If you only check "RETURNING *" then you might not
notice the difference, but with anything else it's obviously wrong.
I propose the attached modification instead.

regards, tom lane

Attachment Content-Type Size
fix-empty-plan-with-RETURNING-2.patch text/x-diff 3.4 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Langote 2019-02-22 02:16:40 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
Previous Message Euler Taveira 2019-02-21 20:54:53 Re: BUG #15648: oracle_fdw extension not able to create