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?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +