From c410af098c46949e36607eb13689e697fa2def97 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 29 Jun 2020 17:12:38 -0400 Subject: Mop up some no-longer-necessary hacks around printf %.*s format. Commit 54cd4f045 added some kluges to work around an old glibc bug, namely that %.*s could misbehave if glibc thought any characters in the supplied string were incorrectly encoded. Now that we use our own snprintf.c implementation, we need not worry about that bug (even if it still exists in the wild). Revert a couple of particularly ugly hacks, and remove or improve assorted comments. Note that there can still be encoding-related hazards here: blindly clipping at a fixed length risks producing wrongly-encoded output if the clip splits a multibyte character. However, code that's doing correct multibyte-aware clipping doesn't really need a comment about that, while code that isn't needs an explanation why not, rather than a red-herring comment about an obsolete bug. Discussion: https://postgr.es/m/279428.1593373684@sss.pgh.pa.us --- src/backend/commands/copy.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'src/backend/commands/copy.c') diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c index 6b1fd6d4cc..3e199bdfd0 100644 --- a/src/backend/commands/copy.c +++ b/src/backend/commands/copy.c @@ -2303,11 +2303,7 @@ CopyFromErrorCallback(void *arg) /* * Make sure we don't print an unreasonable amount of COPY data in a message. * - * It would seem a lot easier to just use the sprintf "precision" limit to - * truncate the string. However, some versions of glibc have a bug/misfeature - * that vsnprintf will always fail (return -1) if it is asked to truncate - * a string that contains invalid byte sequences for the current encoding. - * So, do our own truncation. We return a pstrdup'd copy of the input. + * Returns a pstrdup'd copy of the input. */ static char * limit_printout_length(const char *str) -- cgit v1.2.1