Re: Fwd: Problem with a "complex" upsert

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, 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-30 22:53:00
Message-ID: CAH2-WzkW7pYx5M=NDGcnmPRMmum_jJPSdCVi1w6d=dmcvez-2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs

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.

Thanks
--
Peter Geoghegan

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Amit Langote 2018-07-31 01:11:51 Re: Fwd: Problem with a "complex" upsert
Previous Message Wells Oliver 2018-07-30 17:55:05 Organizing large child tables & indexes for quick seeking

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-07-31 00:26:39 BUG #15305: PREPARE TRANSACTION and pg_create_logical_replication_slot()
Previous Message Tom Lane 2018-07-30 20:21:59 Re: BUG #15248: pg_upgrade fails when a function with an empty search_path is encountered