mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-30 13:41:20 +02:00
96bf88d527
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
33 lines
1.3 KiB
Plaintext
33 lines
1.3 KiB
Plaintext
src/port/README
|
|
|
|
libpgport
|
|
=========
|
|
|
|
libpgport must have special behavior. It supplies functions to both
|
|
libraries and applications. However, there are two complexities:
|
|
|
|
1) Libraries need to use object files that are compiled with exactly
|
|
the same flags as the library. libpgport might not use the same flags,
|
|
so it is necessary to recompile the object files for individual
|
|
libraries. This is done by removing -lpgport from the link line:
|
|
|
|
# Need to recompile any libpgport object files
|
|
LIBS := $(filter-out -lpgport, $(LIBS))
|
|
|
|
and adding infrastructure to recompile the object files:
|
|
|
|
OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o \
|
|
connect.o misc.o path.o exec.o \
|
|
$(filter strlcat.o, $(LIBOBJS))
|
|
|
|
The problem is that there is no testing of which object files need to be
|
|
added, but missing functions usually show up when linking user
|
|
applications.
|
|
|
|
2) For applications, we use -lpgport before -lpq, so the static files
|
|
from libpgport are linked first. This avoids having applications
|
|
dependent on symbols that are _used_ by libpq, but not intended to be
|
|
exported by libpq. libpq's libpgport usage changes over time, so such a
|
|
dependency is a problem. Windows, Linux, and macOS use an export list to
|
|
control the symbols exported by libpq.
|