Re: Fwd: Problem with a "complex" upsert - Mailing list pgsql-bugs

From Dean Rasheed
Subject Re: Fwd: Problem with a "complex" upsert
Date
Msg-id CAEZATCWqLba_VVT1cdaT3YOijESRT8qewLN93Oc7H7ikW2fd-Q@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: Problem with a "complex" upsert  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Fwd: Problem with a "complex" upsert  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-bugs
On 2 August 2018 at 11:38, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Attaching the updated patch, which is quite heavily revised from the
> earlier patch, given the above findings.
>

This doesn't look right to me. It breaks the following case which
currently works in HEAD:

--
drop table if exists foo cascade;
create table foo (a int unique, b text);
create view foo_view as select a as aa, b as bb from foo;

insert into foo_view (aa,bb) values (1,'x');
insert into foo_view (aa,bb) values (1,'y')
  on conflict (aa) do update set bb = excluded.bb;
select * from foo_view;
--

I also don't see why it should reject columns from the view that
aren't in the base relation. Such columns need to remain unchanged in
the UPDATE because they're non-updatable, but they're still logically
part of the new excluded view tuple, and so it may still be useful to
refer to them in other parts of the auxiliary UPDATE.

Regards,
Dean


pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: could not read block 0 in file : read only 0 of 8192 bytes whendoing nasty on immutable index function
Next
From: Ze Victor Harry
Date:
Subject: how to enable pgcrypto