| From: | Scott Dunbar <scott(at)xigole(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #5898: Nested "in" clauses hide bad column names |
| Date: | 2011-02-22 18:07:39 |
| Message-ID: | 4D63FB6B.3060804@xigole.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)xigole(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Farina | 2011-02-22 18:32:53 | Re: Re: 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid |
| Previous Message | Tom Lane | 2011-02-22 17:45:03 | Re: BUG #5898: Nested "in" clauses hide bad column names |