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 →
-
Make pg_dumpall build with the right object files under MSVC.
- 91572ee0a6df 9.2.0 cited
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