Thomas Munro <thomas.mu...@enterprisedb.com> writes:
> On Fri, Oct 13, 2017 at 8:50 AM, Tom Lane <t...@sss.pgh.pa.us> 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 ignored CTEs there, and I do not think the
>> new behavior is an improvement.
> 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 INTO d VALUES (1);
> ^
Well, I think that is a poorly chosen example. Consider this instead:
pre-v10, you could do this:
regression=# create table mytable (f1 int);
CREATE TABLE
regression=# with mytable as (select 1 as x) insert into mytable values(1);
INSERT 0 1
regression=# select * from mytable;
f1
----
1
(1 row)
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.
There may or may not be a case for allowing ENRs to capture names that
would otherwise refer to ordinary tables; I'm not sure. 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.
I think we need to either remove that call from setTargetTable entirely,
or maybe adjust it so it can only find ENRs not CTEs.
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
