From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org>, hugo(dot)mercier(at)oslandia(dot)com, Kevin Grittner <kgrittn(at)gmail(dot)com> |
Subject: | Re: oversight in EphemeralNamedRelation support |
Date: | 2017-10-09 20:43:37 |
Message-ID: | CAEepm=22p8Pc2AJ98pAxY0edDPk0QaAXNT7OjuAR8_GL4D1ARQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 10, 2017 at 2:35 AM, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> Hugo Mercier (in Cc) reported me an error in a query, failing since pg10.
>
> Simple test case to reproduce:
>
> CREATE TABLE public.test (id integer);
> WITH test AS (select 42) INSERT INTO public.test SELECT * FROM test;
>
> which will fail with "relation "test" cannot be the target of a
> modifying statement".
>
> IIUC, that's an oversight in 18ce3a4ab22, where setTargetTable()
> doesn't exclude qualified relation when searching for special
> relation.
I agree.
> PFA a simple patch to fix this issue, with updated regression test.
Thanks!
I suppose we could consider moving the schemaname check into
getRTEForSpecialRelationType(), since otherwise both callers need to
do that (and as you discovered, one forgot).
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2017-10-09 21:13:55 | Re: oversight in EphemeralNamedRelation support |
Previous Message | Jaime Casanova | 2017-10-09 20:23:38 | Re: Columnar storage support |