There are other uses for padding strings besides user reports. Consider scalar representations of computations for example. Also:
1.There was no mention of user display formatting in Ralf's original report. It was a bug report about missing inverse functionality for padding/trimming strings. 2.The proposed functions fully exist in the PostgreSQL archetype. Is PostgreSQL wrong? 3. Why can't SQLite have the expected common static SQL functions for getting rapid development done without external tools? Is the goal to reduce SQL portability and increase development effort just to see some representative output results? I don't think anybody is trying to create production grade displays within SQL but being able to produce representative output and having the expected nucleus of built-in SQL functions (including canonical inverses) is still a sensible goal. On Mon, Feb 19, 2018 at 6:06 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 20 Feb 2018, at 1:38am, petern <peter.nichvolo...@gmail.com> wrote: > > > 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 > > The problem with string length and padding was pointed out upthread. > Padding strings to a length was useful in the days of fixed-width fonts. > We don't do that much these days. And even if you could equip SQLite with > functions which did those things, to do it properly you'd need routines > which understood Unicode characters, combinations, accents and the sort of > diacritics used for Hebrew and Arabic vowels. Without that, you fancy new > feature is just going to trigger hundreds of bug reports. > > String width functions now days take two parameters, the string (in some > flavour of Unicode) and a font descriptor (font, size, emphasis and other > options) and return the width of the string in points, taking into account > not only Unicode features but font features like kern hinting and > ligatures. And you will find these features in your operating system. > > So please, folks, don't try to do this in a purposely tiny DBMS. Do it > using OS calls, as the people who designed your OS intended. > > Simon. > _______________________________________________ > 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
