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
-
Fix INSERT ON CONFLICT UPDATE through a view that isn't just SELECT *.
- 5ad143cda092 9.5.14 landed
- f6a124d019a4 10.5 landed
- e7154b6acfeb 11.0 landed
- b8a1247a34e2 12.0 landed
- b484bffe7d0e 9.6.10 landed