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 <c...@poczta.onet.pl>
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
> 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

Reply via email to