Re: Fwd: Problem with a "complex" upsert
От | Dean Rasheed |
---|---|
Тема | Re: Fwd: Problem with a "complex" upsert |
Дата | |
Msg-id | CAEZATCWqLba_VVT1cdaT3YOijESRT8qewLN93Oc7H7ikW2fd-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: Problem with a "complex" upsert (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Fwd: Problem with a "complex" upsert
|
Список | 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 по дате отправления: