Allow pg_dumpall to use dumpmem.c functions, simplify exit code
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: 2011-11-29T02:38:51Z
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
Attachments
- /rtmp/pg_dump (text/x-diff) patch
Bruce Momjian wrote: > > 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. ... > > I am thinking we should just get rid of the whole AH passing. > > I have always felt the pg_dump code is overly complex, and this is > confirming my suspicion. I have developed the attached patch which accomplishes this. I was also able to move the write_msg function into dumputils.c (which is linked to pg_dumpall), which allows pg_dumpall to use the new dumpmem.c functions, and I removed its private ones. FYI, I found write_msg() was a useless valist trampoline so I removed the trampoline code and renamed _write_msg() to write_msg(). I also modified the MSVC code. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +