Re: pg_dump and premature optimizations for objects not to be dumped - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump and premature optimizations for objects not to be dumped
Date
Msg-id 32571.1452702243@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump and premature optimizations for objects not to be dumped  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump and premature optimizations for objects not to be dumped  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Attached is a draft patch that does things this way.

BTW, the bulk of the changes in this patch are just there to pass down
the DumpOptions struct to where it's needed, following some pre-existing
work that passed that around as a separate pointer.  I wonder why things
were done that way, rather than adding a DumpOptions pointer in the
Archive struct?  The vast majority of the functions I had to touch already
had an Archive* parameter, and would not have needed to be touched if it
were done the other way.  I'm tempted to push a preliminary patch that
adds such a field and gets rid of DumpOptions as a separate parameter
to anything that also takes an Archive* pointer.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Vladimir Sitnikov
Date:
Subject: Re: Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102
Next
From: Pavel Stehule
Date:
Subject: Re: Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102