Re: [COMMITTERS] pgsql: Modify pg_dump to use error-free memory allocation macros. This
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2011-11-26T17:15:39Z
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 →
-
Modify pg_dump to use error-free memory allocation macros. This avoids
- 3c0afde11a12 9.2.0 cited
Tom Lane wrote: > >> 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. > > I don't think there is any "long-term code clarity" gain here that is > worth the maintenance headache. Please put the existing functions back > where they were. Inventing new files for the new code seems fine. Well, you do a lot more backpatching than I do, so I am willing to do as you request, but looking at the git history for common.c, I don't see a lot of backpatching for this file. Basically, if we keep the existing functions in common.c, we are deciding that it is never worth moving C functions to new C files for source code clarity. I was not sure we had made that decision in the past. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +