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. +
