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

Reply via email to