From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mario De Frutos Dieguez <mariodefrutos(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Fwd: Problem with a "complex" upsert |
Date: | 2018-07-31 01:11:51 |
Message-ID: | 2d65f4a8-9a15-7ab6-cb39-d7347deaacd5@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-bugs |
On 2018/07/31 7:53, Peter Geoghegan wrote:
> On Tue, Jul 10, 2018 at 1:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nelson Gonzaga | 2018-08-01 11:12:41 | Grant on lo_export() |
Previous Message | Peter Geoghegan | 2018-07-30 22:53:00 | Re: Fwd: Problem with a "complex" upsert |
From | Date | Subject | |
---|---|---|---|
Next Message | Toshi Harada | 2018-07-31 01:12:19 | Re: BUG #15305: PREPARE TRANSACTION andpg_create_logical_replication_slot() |
Previous Message | Andres Freund | 2018-07-31 00:37:22 | Re: BUG #15305: PREPARE TRANSACTION and pg_create_logical_replication_slot() |