DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer;
	b=lTuBgak9Lsi7r2HkDv4i/oC8BJY73cQv5k3xgt8xVpv3MxvApFaqKodQhQMzpyIvygWtAQnMWE2mjLCoZaz9ZWZwHSlDJkGK+EqQXoUemSAmswAXhyPJJ89T3gwN8bq+BoIr8RhsovYkZmerO90xx7cbZYIxIh0pSqUN09Mm9V8=
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <1B7BB76A-D750-4808-8104-2EC50DDB2FBA@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: pgsql-sql@postgresql.org
From: Rick Innis <rick.innis@gmail.com>
Subject: Misnamed field in subquery does not cause error when field name
	exists in parent query
Date: Sat, 22 Dec 2007 17:12:45 -0500

Wondering if this is actually a bug, before I file a bug report on it.

Consider this sequence:

=# create table public.test1 (id int);
CREATE TABLE
=# create table public.test2 (it int);
CREATE TABLE
=# select * from test1 where id in (select id  from test2);
  id
----
(0 rows)

Note that the select from test2, which references a non-existent  
field, doesn't cause an error when that statement is used as a  
subselect AND the non-existent field does exist in a table referenced  
in the outer select.

This is particularly catastrophic when you replace 'select *' by  
'delete', as illustrated below.

=# insert into test1 values(1);
INSERT 0 1
=# insert into test1 values(2);
INSERT 0 1
=# insert into test1 values(3);
INSERT 0 1
=# delete from test1 where id in (select id  from test2);
DELETE 0
=# select * From test1;
  id
----
   1
   2
   3
(3 rows)

=# insert into test2 values(11);
INSERT 0 1
=# insert into test2 values(12);
INSERT 0 1
=# insert into test2 values(13);
INSERT 0 1
=# delete from test1 where id in (select id  from test2);
DELETE 3
=# select * From test1;
  id
----
(0 rows)

This has bitten me twice, recently, with consequent (though  
recoverable) data loss. It may be that SQL is doing exactly as it  
should, since 'id' is in scope within the subselect, but  if that's  
the case it's a nasty gotcha.

Obviously the subselect, when used as a select, does generate an error.

=# select id  from test2;
ERROR:  column "id" does not exist
LINE 1: select id  from test2;
                ^

Referencing a field that doesn't exist in either also causes an error.

=# select * from test1 where id in (select if  from test2);
ERROR:  column "if" does not exist
LINE 1: select * from test1 where id in (select if  from test2);
                                                 ^
Insight from wiser SQL heads than mine would be appreciated.

	--Rick.