Re: BUG #5898: Nested "in" clauses hide bad column names
От | Scott Dunbar |
---|---|
Тема | Re: BUG #5898: Nested "in" clauses hide bad column names |
Дата | |
Msg-id | 4D63FB6B.3060804@xigole.com обсуждение исходный текст |
Ответ на | Re: BUG #5898: Nested "in" clauses hide bad column names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #5898: Nested "in" clauses hide bad column
names
Re: BUG #5898: Nested "in" clauses hide bad column names |
Список | pgsql-bugs |
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"<scott@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
В списке pgsql-bugs по дате отправления: