"Peter J. Holzer" <hjp-pgsql@xxxxxx> 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
