On Tue, 3 Sep 2013 18:37:42 -0500
Nico Williams <[email protected]> wrote:
> > There's no need to qualify string literals, as it turns out. SQLite
> > makes a reasonable choice in that context. When comparing a string
> > literal to a column, the literal (in effect) takes on the collation
> > of the column.
>
> But SQLite3 is dynamically typed. Consider a query that uses a UNION
> query as a table source, where the corresponding columns of the
> sub-queries use different collations.
Each column has a type, and every character column has a collation.
Each individual value, each row, is compared to the string literal on
its own terms.
When you say
where NAME = 'George'
the only reasonable thing to do is to compare each NAME with 'George'.
Even if different NAMEs have different collations (as in a UNION,
perhaps), each individual NAME has a particular collation, which
governs the comparison.
> It's easy to build contrived (and real) queries where SQLite3 can't
> keep track of a collation -- not at run-time, much less at query
> compile-time.
I might regret this, but if it's easy could you perhaps provide
an example?
--jkl
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
