[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-hackers
Subject:    Re: [HACKERS] Allow pg_dumpall to use dumpmem.c functions,
From:       Bruce Momjian <bruce () momjian ! us>
Date:       2011-11-29 21:35:18
Message-ID: 201111292135.pATLZI623135 () momjian ! us
[Download RAW message or body]

Bruce Momjian wrote:
> 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.

Applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]