Yes, you're correct. I guess this makes sense but it does seem strange
that I can enter garbage in a query but it still runs. And in my case
the output from this (the entire table) was then used in a delete
statement that toasted the entire table. Allowing bogus SQL just seems
"wrong" but I do understand what's going on.
Thanks for your help.
On 02/22/2011 10:45 AM, Tom Lane wrote:
"Scott Dunbar"<sc...@xigole.com> writes:
I have a nested in clause like:
select respondent_id from respondent where respondent_id in (select
respondent_id from chat_session where project_id in (select project_id from
project where company_id = 4));
However, in this example, there is no column named respondent_id in the
chat_session table.
Probably there is one in respondent, though? This behavior is not a bug
--- what you have there is an outer reference, and it is working exactly
as specified by the SQL standard. Sub-selects would be a whole lot less
useful if they couldn't refer to variables of the outer query.
regards, tom lane
--
Scott Dunbar
Xigole Systems, Inc.
Enterprise software consulting, development, and hosting
303·667·6343
