Thomas Munro writes:
> On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote:
>> But I see very
>> little case for allowing CTEs to capture such references, because surely
>> we are never going to allow that to do anything useful, and we have
>> several years of precedent now that they don't capture.
On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote:
> But I see very
> little case for allowing CTEs to capture such references, because surely
> we are never going to allow that to do anything useful, and we have
> several years of precedent now that they don't capture.
For what it's worth, SQL Se
On Fri, Oct 13, 2017 at 5:22 AM, Tom Lane wrote:
> Thomas Munro writes:
>> On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote:
>>> Yeah, I agree --- personally I'd never write a query like that. But
>>> the fact that somebody ran into it when v10 has been out for barely
>>> a week suggests that p
Thomas Munro writes:
> On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote:
>> Yeah, I agree --- personally I'd never write a query like that. But
>> the fact that somebody ran into it when v10 has been out for barely
>> a week suggests that people are doing it.
> Not exactly -- Julien's bug repor
On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote:
> Thomas Munro writes:
>> On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote:
>>> The CTE was simply not part of the available namespace for the INSERT's
>>> target, so it found the regular table instead. v10 has thus broken
>>> cases that used to
Thomas Munro writes:
> On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote:
>> The CTE was simply not part of the available namespace for the INSERT's
>> target, so it found the regular table instead. v10 has thus broken
>> cases that used to work. I think that's a bug.
> Hmm. Yeah. I have to s
On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote:
> Thomas Munro writes:
>> Before that, CTE used as modify targets produced a different error message:
>
>> postgres=# WITH d AS (SELECT 42) INSERT INTO d VALUES (1);
>> ERROR: relation "d" does not exist
>> LINE 1: WITH d AS (SELECT 42) INSERT IN
Thomas Munro writes:
> On Fri, Oct 13, 2017 at 8:50 AM, Tom Lane wrote:
>> Hm. I actually think the bug here is that 18ce3a4ab introduced
>> anything into setTargetTable at all. There was never previously
>> any assumption that the target could be anything but a regular
>> table, so we just ign
On Fri, Oct 13, 2017 at 8:50 AM, Tom Lane wrote:
> Julien Rouhaud writes:
>> On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro
>> wrote:
>>> I suppose we could consider moving the schemaname check into
>>> getRTEForSpecialRelationType(), since otherwise both callers need to
>>> do that (and as you d
Julien Rouhaud writes:
> On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro
> wrote:
>> 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).
> Thanks for the feedback. That
On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro
wrote:
>
> 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).
Thanks for the feedback. That was my first idea, but I assum
On Tue, Oct 10, 2017 at 2:35 AM, Julien Rouhaud 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 fai
Hi,
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 stat
13 matches
Mail list logo
