diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-09-26 13:13:57 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-09-26 13:13:57 -0400 |
commit | 96bf88d52711ad3a0a4cc2d1d9cb0e2acab85e63 (patch) | |
tree | 5fe0dd88e19f308167a9d17c19b372012573dd8e /src/common/psprintf.c | |
parent | 758ce9b7794845f95473c569155d29fcf0e2751b (diff) | |
download | postgresql-96bf88d52711ad3a0a4cc2d1d9cb0e2acab85e63.tar.gz postgresql-96bf88d52711ad3a0a4cc2d1d9cb0e2acab85e63.zip |
Always use our own versions of *printf().
We've spent an awful lot of effort over the years in coping with
platform-specific vagaries of the *printf family of functions. Let's just
forget all that mess and standardize on always using src/port/snprintf.c.
This gets rid of a lot of configure logic, and it will allow a saner
approach to dealing with %m (though actually changing that is left for
a follow-on patch).
Preliminary performance testing suggests that as it stands, snprintf.c is
faster than the native printf functions for some tasks on some platforms,
and slower for other cases. A pending patch will improve that, though
cases with floating-point conversions will doubtless remain slower unless
we want to put a *lot* of effort into that. Still, we've not observed
that *printf is really a performance bottleneck for most workloads, so
I doubt this matters much.
Patch by me, reviewed by Michael Paquier
Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
Diffstat (limited to 'src/common/psprintf.c')
0 files changed, 0 insertions, 0 deletions