From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: insert on conflict on updatable views |
Date: | 2018-08-02 02:24:44 |
Message-ID: | CAH2-WzmjVXfFbhPnz+rAKKL+7S7f_StrbQ=iomhBpu3k2dvNOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 1, 2018 at 7:15 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> create table foo (a int unique, b text);
> create view foo_view as select b, a+1 as c, a from foo;
>
> explain insert into foo_view (a, b) select 1, 2 on conflict (a) do update
> set b = excluded.b where excluded.c > 0;
> IOW, the EXCLUDED pseudo-relation should only allow referencing the
> columns present in the underlying physical relation. Thoughts?
EXCLUDED represents the values that the user attempted to insert, so
it's arguably useful that EXCLUDED.c is accessible here, even though
the target rel doesn't have a "c" column.
Do you have some particular practical problem in mind here, or are you
just concerned about the semantics being exactly consistent?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-08-02 02:51:58 | Re: Explain buffers wrong counter with parallel plans |
Previous Message | Amit Langote | 2018-08-02 02:15:14 | insert on conflict on updatable views |