On Mon, Feb 19, 2018 at 7:49 PM, petern <[email protected]> wrote:
> 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. > > I agree completely; however, what ARE standard SQL functions? I went searching and found 4 different answers. Wriiting common SQL is pretty hard so I have always avoided any internal functions and forced the application to do it.... LTRIM( " ", 4-LENGTH(whategver)) ||whatever would seem to do the padding? Could wish there was a public SQL standard readable... while I understand they need to make money too; makes it hard to find reference material to state well... according to 'The Standard' Sqlite is missing XXX. Unfortunately earlier 3 databases with 3 different functions to do the same thing, (SUBSTR is another?) it doesn't appear there is a desire for concensus either.... > On Mon, Feb 19, 2018 at 6:06 PM, Simon Slavin <[email protected]> > wrote: > > > On 20 Feb 2018, at 1:38am, petern <[email protected]> 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 > > [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 > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
