Andres Freund <and...@2ndquadrant.com> writes:
> elog.c's log_line_prefix() processes %d with:
> case 'd':
> if (MyProcPort)
> {
> const char *dbname = MyProcPort->database_name;
> if (dbname == NULL || *dbname == '\0')
> dbname = _("[unknown]");
> if (padding != 0)
> appendStringInfo(buf, "%*s", padding, dbname);
Not directly related to your gripe, but: where did this "padding" logic
come from, and what prevents it from creating invalidly-encoded output by
means of truncating multibyte characters in the middle? Not to mention
that if glibc has a different idea of the prevailing encoding than we do,
it is quite likely to mess up completely. We've been burnt badly enough
by use of this coding technique that it should never have been accepted in
someplace as critical as elog.c.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
