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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden