On Wed, Jun 1, 2011 at 12:32 AM, Roger Binns <rog...@rogerbinns.com> wrote:
> It does seem to me that this specific example is "wrong". Selects return
> zero or more rows yet the equality wants exactly one value. I would expect
> an error rather an implied "LIMIT 1" should there be anything other than
> exactly one row. In some cases you'd only know by executing that subquery
> how many rows it returns, rather than at prepare time.
This is my general feeling as well, but I'm ignoring this since I'm
okay with erroneous queries generating ambiguous results.
>>> So, in summary, the "problem" has been with us for 6 years and nobody has
>>> cared. And "fixing" it reduces the battery life on your cellphone by some
>>> small amount. Are you *sure* this is something that needs to change?
>
> I think it is important to correct, especially as there is no workaround.
The fact that there is no straight-forward work-around is the most
problematic part. One possible work-around would be to build a
tokenizer that re-extracts all the SQLite parameters so their values
can be verified. Another possibility is to completely ignore missing
named parameters, leading to the inability to detect errors for the
user. Understanding the query would be more of a leap, so I don't
think it's a reasonable solution to attempt to remove the "extra"
parameter.
>From these, the "best" solution seems to be re-tokenizing the sql in
the provider. Is there another work-around? It seems that
implementing this at the database level would be the most efficient
approach. Obviously re-tokenizing all the SQL would be expensive.
Patrick Earl
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
