Re: pgsql: Modify pg_dump to use error-free memory allocation macros. This
От | Bruce Momjian |
---|---|
Тема | Re: pgsql: Modify pg_dump to use error-free memory allocation macros. This |
Дата | |
Msg-id | 201111261450.pAQEoPV26144@momjian.us обсуждение исходный текст |
Ответ на | Re: pgsql: Modify pg_dump to use error-free memory allocation macros. This (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-committers |
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > Modify pg_dump to use error-free memory allocation macros. This avoids > > > ignoring errors and call-site error checking. > > > > This appears to have broken the MSVC build. More generally, I'd like to > > Doesn't the MSVC build scrape the Makefiles? Looking at Mkvcbuild.pm, > it seems it doesn't for pg_dump? When exactly does the MSVC build have > to be adjusted for makefile changes? > > I will adjust Mkvcbuild.pm, assuming we want to keep this change. > > > object to arbitrarily moving a bunch of longstanding code from one file > > to another. What that is mainly going to accomplish is creating a big > > headache whenever we have to back-patch fixes that touch that code > > ... and what exactly did it buy in return? > > Yes, I didn't like that either. The problem was that common.c was setup > to share code between pg_dump and a long-forgotten tool for Postgres 4.X > called pg4_dump (yes, pre-1996). That code that was moved was really > not "common" in any current sense because it was used only by pg_dump > (not by pg_restore or pg_dumpall), so I moved it into dumpcatalog.c, and > put the really "common" code into common.c. (We could call it dumpmem.c > or something.) > > Now, one approach would have been to rename common.c to dumpcatalog.c in > git, then create a new common.c, but that seems quite confusing to > people trying to reconstruct the history. > > It is not possible to just link the old common.c into pg_restore and > pg_dumpall because it contains calls to pg_dump-only functions. > > Ideas? The only other idea I have is to keep most functions in the mis-named common.c and move the memory functions into dumpmem.c and dumpmem.h and include that in the other C files, but that doesn't help with long-term code clarity. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-committers по дате отправления: