Absolutely agree; only mention that my request for "a 16 bit version of the sqlite3_get_table" refers to a UTF-16 version -as usual in the actual C/C++ API-.
Of course, besides -or instead- the requested function, would be great disclose the SQLite UTF-8/UTF-16 conversion mechanism. A.J.Millan ----- Original Message ----- From: "Nicolas Williams" <nicolas.willi...@sun.com> > On Tue, Sep 01, 2009 at 10:41:27AM +0200, A.J.Millan wrote: >> * Make sure there was no 16-bit version of the sqlite3_get_table at >> function -perhaps it would be a good idea to include it in the standard >> API. >> The reason is the same who advised include the current version. > > It might be easier to provide utility functions for UTF-8<->UTF-16 > conversion and let developers use those when 16 variants of various > functions are missing. > > (Yes, there should be libraries in your OS for UTF-8<->UTF-16 > conversion, but SQLite3 already has its own. Exporting them should not > hurt.) > > But wchar_t <-> UTF-8 and wchar_t <-> UTF-16 conversions should > definitely be out of scope for SQLite3. (wchar_t is very OS- and > locale-specific. Expecting SQLite3 to know about wchar_t seems to me > like asking for bloat.) > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
