parser should trigger an error if a
subquery selects unknown columns from table
I ran into a similar issue:
DELETE FROM ATable WHERE EXISTS(SELECT 1 FROM TMPTable AS t WHERE id =
t.id) ;
Syntactically I was expecting id to be the ATable.id as I had aliased the
TMPTable with t. But the result
I ran into a similar issue:
DELETE FROM ATable WHERE EXISTS(SELECT 1 FROM TMPTable AS t WHERE id =
t.id) ;
Syntactically I was expecting id to be the ATable.id as I had aliased the
TMPTable with t. But the result was a
non-correlated subquery, id = t.id was always true. The fix is clear, yet
On Wed, May 1, 2013 at 3:23 PM, Anderson Medeiros Gomes
wrote:
> Hi. I think I found a bug in SQLite, so I'm reporting it in this message.
>
> The print screen I have attached shows a query that SQLite executes and
> brings no results. I believe SQLite should trigger an error
On Wed, May 1, 2013 at 2:23 PM, Anderson Medeiros Gomes
wrote:
> Hi. I think I found a bug in SQLite, so I'm reporting it in this message.
I do't think it's a bug. Correlated sub-queries can refer to columns
from table sources outside them. Your example query is silly, no
Hi. I think I found a bug in SQLite, so I'm reporting it in this message.
The print screen I have attached shows a query that SQLite executes and
brings no results. I believe SQLite should trigger an error while parsing
my input, because I used an unknown column in the subquery.
This is the
5 matches
Mail list logo