Re: [HACKERS] pg_dump not in very good shape
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] pg_dump not in very good shape |
Дата | |
Msg-id | Pine.LNX.4.21.0001161828190.1636-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | pg_dump not in very good shape (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pg_dump not in very good shape
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: