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  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: could not read block 0 in file : read only 0 of 8192 bytes whendoing nasty on immutable index function
Следующее
От: Ze Victor Harry
Дата:
Сообщение: how to enable pgcrypto