Thomas Munro <thomas.mu...@enterprisedb.com> writes:
> On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane <t...@sss.pgh.pa.us> 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 say it's a bit surprising that the following
> refers to two different objects:
> with mytable as (select 1 as x) insert into mytable select * from mytable
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.
>> I think we need to either remove that call from setTargetTable entirely,
>> or maybe adjust it so it can only find ENRs not CTEs.
> I think it'd be better to find and reject ENRs only. The alternative
> would be to make ENRs invisible to DML, which seems arbitrary and
> weird (even though it might be more consistent with our traditional
> treatment of CTEs). One handwavy reason I'd like them to remain
> visible to DML (and be rejected) is that I think they're a bit like
> table variables (see SQL Server), and someone might eventually want to
> teach them, or something like them, how to be writable.
Yeah, that would be the argument for making them visible. I'm not
sure how likely it is that we'll ever actually have writable ENRs,
but I won't stand in the way if you want to do it like that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
