-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexey Pechnikov wrote: > This is standart for all i18n applications.
The SQLite shell is not an i18n application, and this is deliberate. It is a developer tool. That is why for example it always uses a dot for a decimal point and not a comma even if that is what the locale does. The output is always the same wherever it is used. (Same thing applies for input.) > The SQLite virtualtables can > perform access to filesystem, read/write scv files and other - how they can > to > determine the current locale? That is indeed trickier. But even your example is hard. If I am sitting in Canada and get a German CSV file, which locale applies? Virtual tables are analogous to libraries and so cannot always rely on the hosting process. Additionally many processes these days have multiple libraries (and virtual tables if appropriate) so requiring things setup just for one is not helpful. For example if the process is serving web requests it may want the locale to match the user not the server, and potentially change on each request. In your particular scenario I'd add some sort of explicit parameter for the virtual table that allows specifying the locale, with perhaps an empty string/null meaning look at the environment variables or code page as a fallback. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkskIrwACgkQmOOfHg372QSS/gCeI6KPWCJzK54VFL4JN804ryiK YwMAoMJcgHqAXxbLreuxgLurT2diFjcw =Kq1K -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
