On Fri, 10 Feb 2017 20:57:34 +0100 Dominique Devienne <ddevie...@gmail.com> wrote:
> the view itself calls printf. I see now. Your request is very specific: to support a thousands separator in the SQL printf. You don't want to write a UDF, and you don't want to use any facilities above the API (in C or other). I doubt you'll win that argument. Hard-coding the separator (insensitive to locale) won't sit well, nor will introducing locale to the SQLite code. Locale-dependent behavior in a library is tricky. To use the features in libc, setlocale(3) must be called first. But who should call it? The SQLite library can't call it, else it provokes locale-dependent behavior in an application that might not want it, or might want something other than the default. OTOH, by leaving it up to the application, SQLite's observed behavior becomes not only locale-dependent, but dependent on when/if/how setlocale(3) is called. FWIW it's my belief that printf doesn't belong in SQL. SQL is a query language, not a report-writing tool. I mean, what about headers and footers, and page numbers? I'm not being facetious: report-writing has all kinds of needs besides formating numbers that you would never suggest belong in SQL. So what's the point in supporting this one aspect, knowing that any real report will have to resort to host-language formatting features anyway? I think there's pretty much always a case to be made to improve the formatting capabilities of the SQLite shell, both for user convenience and simple reports. But that's a separate discussion, and not what you asked for. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
