"Marko Kreen" <markokr@gmail.com> writes: > Attached patch moves decision how much more room to allocate > from callers of appendStringInfoVA to inside the function, > where more info is available. This is by no stretch of the imagination "cleaner". > On systems with broken vsnprintf() it falls back > to doubleing the buffer. The problem with this is that you are defining one particular vsnprintf behavior as "non broken", without any evidence for that opinion. (Indeed, one could argue that that behavior is contradictory to what the Single Unix Spec says, although the SUS is a bit vague about it.) Our own vsnprintf doesn't follow that behavior, for instance, so we couldn't even get there by forcing it to be used always. I'd want to see some significant evidence of a performance issue before considering hacking this up like this. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

"Marko Kreen" <markokr@gmail.com> writes: > FWIW, SUS says that vsnprintf should act like snprintf and snprintf: I dunno where you're reading that, but it's certainly nowhere to be found in the version that I read: http://www.opengroup.org/onlinepubs/007908799/xsh/vfprintf.html regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster