Re: pgsql: Make pg_dumpall build with the right object files under MSVC.

Alvaro Herrera <alvherre@commandprompt.com>

From: Alvaro Herrera <alvherre@commandprompt.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>, Pg Committers <pgsql-committers@postgresql.org>
Date: 2011-11-28T17:48:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Make pg_dumpall build with the right object files under MSVC.

Excerpts from Andrew Dunstan's message of lun nov 28 14:40:24 -0300 2011:
> 
> On 11/28/2011 11:33 AM, Bruce Momjian wrote:

> > In summary, for those watching, pg_dump and pg_restore used to share
> > OBJS, and with my new patch, dumpmem.c is now shared by those and
> > pg_dumpall.  Seems the MSVC code previously could not handle that case,
> > which is fixed by this patch.
> 
> Er, no. Only dumputils.c is shared with pg_dumpall. dumpmem.c is not 
> (see the Makefile).
> 
> The problem that arose is that pg_dumpall has its own (non-static) 
> versions of pg_malloc and pg_strdup, so we got duplicate symbol errors 
> from the newly declared dumpmem.c functions when we erroneously tried 
> linking it in on MSVC.

I was wondering if it wouldn't make more sense to have pg_dumpall supply
its own version of exit_horribly to avoid separate pg_malloc and
pg_strdup ... but then those routines are so tiny that it hardly makes a
difference.

Another thing I wondered when seeing the original commit is the fact
that the old code passed the AH to exit_horribly in some places, whereas
the new one simply uses NULL.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support