FYI. See http://www.sqlite.org/src/timeline for the equivalent DRH checkins: http://www.sqlite.org/src/info/c883c4d33f4cd722 Hopefully that branch will make a forthcoming trunk merge. [Printing explicit nul terminator by formatting an interesting twist.]
Yet even so, as Ralf pointed out, the PostgreSQL lpad() and rpad() fill with arbitrary string functionality would still be missing despite the checked in printf() being more directly equivalent to the PostgreSQL format() function. First things first I suppose... PostgreSQL lpad() and rpad() documentation is here: https://www.postgresql.org/docs/9.5/static/functions-string.html Peter On Mon, Feb 19, 2018 at 4:38 PM, Cezary H. Noweta <[email protected]> wrote: > Hello, > > On 2018-02-17 18:39, Ralf Junker wrote: > >> Example SQL: >> >> select >> length(printf ('%4s', 'abc')), >> length(printf ('%4s', 'äöü')), >> length(printf ('%-4s', 'abc')), >> length(printf ('%-4s', 'äöü')) >> >> Output is 4, 3, 4, 3. Padding seems to take into account UTF-8 bytes >> instead of UTF-8 code points. >> >> Should padding not work on code points and output 4 in all cases as >> requested? >> > > If you are interested in a patch extending a functionality of ``printf()'' > then http://sqlite.chncc.eu/utf8printf/. Adding ``l'' length modifier > makes width/precision specifications being treated as numbers of UTF-8 > chars -- not bytes. ``SELECT length(printf ('%4ls', 'äöü'));'' will give 4. > > -- best regards > > Cezary H. Noweta > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
