Re: Fwd: Problem with a "complex" upsert

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mario De Frutos Dieguez <mariodefrutos@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2018-07-31T01:11:51Z
Lists: pgsql-bugs
On 2018/07/31 7:53, Peter Geoghegan wrote:
> On Tue, Jul 10, 2018 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I tried debugging why that happens and concluded that rewriteTargetView
>>> fails to *completely* account for the fact that the view's column's may
>>> have different attribute numbers than the underlying table that the DO
>>> UPDATE action will be applied to.  Especially, even if the view's Vars are
>>> replaced with those corresponding underlying base table's columns, the
>>> TargetEntry's into which those Vars are contained are not refreshed, that
>>> is, their resnos don't match varattnos.
>>
>>> I created a patch that seems to fix the issue, which also adds a
>>> representative test in updatable_view.sql.
>>
>> Hm.  I looked at this patch a bit.  While the onConflictSet change looks
>> reasonable, I find the exclRelTlist change fishy.  Shouldn't those resnos
>> correspond to the exclRelTlist's *own* vars, independently of what is or
>> isn't in the view_targetlist?  And why is it OK to ignore failure to find
>> a match?
> 
> Any update on this, Amit? I would like to get this one out of the way soon.

This has slipped my mind.  I will look into updating the patch today.

Thanks,
Amit



Commits

  1. Fix INSERT ON CONFLICT UPDATE through a view that isn't just SELECT *.