Andres Freund <and...@2ndquadrant.com> writes: > On 2014-05-16 15:44:53 -0400, Tom Lane wrote: >> But according to previous research, we don't >> really guarantee that glibc thinks the encoding is what we think, anyway. >> The commit messages for 54cd4f04576833abc394e131288bf3dd7dcf4806 and >> ed437e2b27c48219a78f3504b0d05c17c2082d02 are relevant here. The second >> one suggests that only "%.*s" is at risk not "%*s", but I'm not really >> convinced right now. My recollection is that glibc will abandon >> processing either format spec if it thinks the string is wrongly encoded.
> I've tested it here. From what it looks like it prints just fine but > misjudges the width for padding. Oh, good. We can live with that. > You propose to revert? Not if the data gets printed. I was afraid it wouldn't be. (In any case, we could retain the feature and just do the padding computations ourselves. But I now think we don't have to.) 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