"Peter J. Holzer" <hjp-pgsql@hjp.at> writes:
> On 2020-10-17 20:51:36 +0200, Matthias Apitz wrote:
>> El día sábado, octubre 17, 2020 a las 03:37:46p. m. -0300, Celso Lorenzetti escribió:
>>> elog(INFO, "\n%-10s Fim\n%-10s Fim\n", "Variável", "Variavel");
> Which programming language is this? PL/pgSQL?
Looks like C in the backend.
>> The second test (changing the accented char 'á' by 'X'), shows that the
>> problem/bug is a) more generic, not only in PostgreSQL and b) has todo
>> with being the UTF-8 char 'á' a two byte char, while 'X' is only one
>> byte.
> Yes, determining how much space a UTF-8 sequence occupies on screen is
> surprisingly hard. I'm not sure what the C standard says about that. But
> these days I would expect any programming language to get it right at
> least for the simple cases.
Our version of snprintf intentionally counts bytes not characters,
so that it does not have to make assumptions about what encoding
the given string uses. It's somewhat unclear whether the C/POSIX
standard mandates either of these interpretations. The GNU
implementation of snprintf tries to count characters. But in the
cases where that's mattered to us at all, it's generally been the
wrong thing, because glibc didn't necessarily know the encoding to
use. That's one reason why we stopped relying on libc's snprintf.
The way to get this to work as Celso wishes would be to count
characters and then do his own arithmetic about how much padding
to add.
regards, tom lane