Re: Fwd: Problem with a "complex" upsert
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Mario De Frutos Dieguez <mariodefrutos@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2018-08-03T06:52:38Z
Lists: 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
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