Re: BUG #16520: Deleting from non-existent column in CTE removes all rows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jesse007(at)ymail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16520: Deleting from non-existent column in CTE removes all rows
Date: 2020-06-30 18:34:05
Message-ID: 494165.1593542045@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> This will throw an error that the column does not exist:
> ```
> WITH to_delete AS (
> SELECT MIN(id), username
> FROM test
> GROUP BY username
> HAVING count(*) > 1
> )
> SELECT id
> FROM to_delete;
> ```

Sure, because the columns exposed by to_delete are named "min" and
"username", not "id".

> However, the this will not return an error and instead deletes all rows:
> ```
> WITH to_delete AS (
> SELECT MIN(id), username
> FROM test
> GROUP BY username
> HAVING count(*) > 1
> )
> DELETE FROM test
> WHERE id IN (
> SELECT id
> FROM to_delete
> );
> ```

You've been bit by the standard SQL newbie trap that sub-selects
allow outer references. That IN clause devolves to constant true
(at least for non-null id values, and with to_delete known not
empty), because it's just "id = id".

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Meskes 2020-06-30 18:47:11 Re: [BUG][PATCH] ecpg crash with bytea type and cursors
Previous Message Michael Meskes 2020-06-30 18:15:23 Re: [BUG][PATCH] ecpg crash with bytea type and cursors