The generated limit parameter does have a value of 1, so it's a valid
query. It's SQLite that has taken this valid query with a valid
parameter value of 1 and has exposed its internal implementation
details by removing it and causing additional work-arounds in
parameter binding. It's possible the work-arounds aren't major... I
haven't had time to look at the picture in depth.
Patrick Earl
On Tue, May 31, 2011 at 12:47 PM, Jan Hudec <[email protected]> wrote:
> On Tue, May 31, 2011 at 08:00:40 -0400, Richard Hipp wrote:
>> On Mon, May 30, 2011 at 11:27 PM, Patrick Earl <[email protected]> wrote:
>> > SELECT this_.studentId as studentId143_0_,
>> > this_.Name as Name143_0_,
>> > this_.address_city as address3_143_0_,
>> > this_.address_state as address4_143_0_,
>> > this_.preferredCourseCode as preferre5_143_0_
>> > FROM Student this_
>> > WHERE this_.Name = (
>> > SELECT this_0_.Name as y0_
>> > FROM Student this_0_
>> > WHERE this_0_.studentId = @p0
>> > ORDER BY this_0_.Name
>> > asc limit @p1)
>> [...]
>>
>> The LIMIT in a scalar subquery is always ignored. A scalar subquery
>> operates with a LIMIT of 1 regardless of any LIMIT that you might specify.
>
> It's quite obvious that any other limit in a scalar subquery does not make
> sense, not only in SQLite, but in any SQL database, since only one value will
> ever be used. Which leads me to wonder what causes it to be generated (you
> don't want to tell me the weird names are invented manually, right?) and
> whether
> - it should have not generated the limit, or
> - it should have used "in" instead of "=" (thus making it list query which
> can meaningfuly have limit).
>
> --
> Jan 'Bulb' Hudec <[email protected]>
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
