Re: [HACKERS] pg_dump not in very good shape

On 2000-01-15, Tom Lane mentioned:

> I am inclined to go ahead and insert vsnprintf into libpq.
> The risk of problems seems pretty small (and it's zero on any
> machine with a reasonably recent libc, since then vsnprintf
> will be in libc and we won't link our version). The risk of
> missing a buffer-overrun condition in pg_dump, and shipping
> a pg_dump that will fail on someone's database, seems worse.
>
> Comments? Better ideas?

I think including this in libpq is the wrong way to go. It's not meant for
external clients. If you open this can of worms then anything psql or
pg_dump feel like using that day becomes part of the library interface.
We'd be stuck with supporting this forever.

A better idea would be to do what psql does with snprintf: Just include
the [v]snprintf.o file in the compilation (linking) conditionally. (Of
course a better plan might even be consolidating all the backend/port and
utils stuff into one unified port directory that everyone in the source
tree can use, but that's probably too much bother right now.)

One thing that I hope I can tackle for 7.1 is cleaning up the build
process (with automake?) and that would take care of missing functions
automatically by substituting a replacement contained in the distribution,
as I suggested above.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden