On Thu, Aug 29, 2013 at 6:35 PM, James K. Lowden <jklow...@schemamania.org> wrote: > On Tue, 27 Aug 2013 21:00:50 -0500 > Nico Williams <n...@cryptonector.com> wrote: > >> Of course, lacking a syntax for associating collations with string >> literals there will be times when some, or even all of the operands to >> an operation that needs collation information, is missing. In such >> cases the collation information of some operands could be used to cast >> the others, or lexical clues might be needed, or a default might be >> provided. > > 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. 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. One might say that such cases are programmer error, but they are supported nonetheless. Still, as long as BETWEEN, IS, =, and so on, have a way to consistently derive a collation from one or more of their operands then things can be OK. CAST can serve that purpose, and if users choose to think of it as providing a collation for the operator, so be it (though it is subtly not the same). BTW, looking at struct Mem, I don't see SQLite3 keeping track of collations in string values. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
