If the `printf` function could add a thousands separator there I are times I would have used it! Instead I've ended up using a recursive CTE and `||` operators to build up the string. I can't find the query right now.
Maybe the CLI tool is a better place for the feature, I suggest either as a function like `readfile(X)` and `writefile(X, Y)` or as a dot command like `.width`. As an aside I started to use `printf` less when I realised that in the CLI `.width` can right align numbers. I would certainly be another user of the feature if it were available within SQLite somewhere. On 11 February 2017 at 02:43, James K. Lowden <jklow...@schemamania.org> wrote: > 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 _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
