Re: Enhancement request for pg_dump

fyi, if you have a feature request or enhancement, then the proper place
for that is here -> https://postgresql.uservoice.com/forums/21853-general

On Sun, Apr 17, 2016 at 8:26 PM, Sergei Agalakov <
Sergei(dot)Agalakov(at)getmyle(dot)com> wrote:

> I hardly can see that a sorting of the grants by users will create a
> measurable impact on the pg_dump performance in a real database.
> One can imaging a database with tens of thousands of objects and tens of
> thousands of users and almost no data, but it would be quite unusual.
> Anyway, if a sorting behavior is initiated by a command line parameter,
> and isn't a default behavior of pg_dump then this argument doesn't work.
> After all pg_dump isn't the tool to do _just_ reliable backup. It can be
> used for migration, it can be used for schema cloning, to initiate a
> standby...
> There are many flags for pg_dump that are absolutely unnecessary for full
> database backup. So they do
> "... might also overcomplicate it, making it more difficult to maintain
> reliably" but they do exists, and serve a purpose.
>
> I don't understand why people have started to create the theories about
> our development process? Had I requested a tool to magically synchronize
> DEV and PROD? No, I asked about a tool to _find_ the unexpected
> differences between databases. If you never encountered a situation when in
> the
> dozens of environments the databases has diverged because somebody has
> done something manually - good for you, you are lucky guy then.
> I did.
>
> Sergei
>
>> On Sun, 17 Apr 2016 14:10:50 -0600
>> Sergei Agalakov <Sergei(dot)Agalakov(at)getmyle(dot)com> wrote:
>>
>> > I don't see how these questions are related to the proposed pg_dump
>> > improvement.
>> > I suggest to improve pg_dump so it can be used instead of the third
>> > party tools like DBSteward and SQLWorkbench/J etc.
>> > to compare two different databases or existing dumps, and to identify
>> > the differences. The use cases will be exactly
>> > the same as for the third party tools. The positive difference will be
>> > that pg_dump is a very reliable, always available and supports all the
>> > latest PostgreSQL features.
>> > Do you imply that there shouldn't be any reasons to compare different
>> > databases to find the differences between them?
>>
>> Nobody has weighed in on this, but I have a theory ...
>>
>> I (personally) worry that adding features like you suggest to pg_dump
>> would interfere with its ability to perform complete dump of a large
>> database in a _rapid_ manner. Using pg_dump as a backup tool has an
>> inherent desire for the tool to be as fast and low-impact on the
>> operation of the database as possible.
>>
>> Features that would force pg_dump to care about ordering that isn't
>> necessary to its core functionality of providing a reliable backup
>> are liable to slow it down. They might also overcomplicate it, making
>> it more difficult to maintain reliably.
>>
>> When you consider that possibility, and the fact that pg_dump isn't
>> _supposed_ to be a tool to help you with schema maintenance, it's easy
>> to see why someone would look for different approach to the problem.
>>
>> And I feel that's what all the answers have attempted to do: suggest
>> ways to get what you want without asking them to be implemented in a
>> tool that isn't really the right place for them anyway. While your
>> arguments toward making this change are valid, I'm not sure that
>> they are compelling enough to justify adding a feature where it
>> doesn't really belong.
>>
>> Another side to this, is that your request suggests that your
>> development process is suboptimal. Of course, I can't be 100% sure
>> since you haven't explained your process ... but my experience is
>> that people who feel the need to automagically sync prod and dev
>> databases have a suboptimal development process. Thus, the suggestions
>> are also biased toward helping you improve your process instead of
>> adjusting a tool to better support a suboptimal process.
>>
>> Of course, if the people actually doing the work on the code disagree
>> with me, then they'll make the change. I'm just expressing an opinion.
>>
>> > Sergei
>> >
>> > > > On Apr 17, 2016, at 12:41 PM, Sergei Agalakov
>> <Sergei(dot)Agalakov(at)getmyle(dot)com> wrote:
>> > > >
>> > > > I know about DBSteward. I don't like to bring PHP infrastructure
>> only to be able to compare two dumps,
>> > > > and to deal with potential bugs in the third party tools. The
>> pg_dump in other hand is always here, and is always trusted.
>> > > > SQLWorkbench/J also can compare two schemas, and requires only
>> Java. Again, I trust pg_dump more.
>> > > >http://www.sql-workbench.net/
>> > > >
>> > > > May be pg_dump was never INTENDED to generate the dump files with
>> the determined order of the statements,
>> > > > but it CAN do it with the minor changes, and be more useful to
>> administrators. Why rely on the third party tools
>> > > > for the tasks that can be done with the native, trusted tools?
>> > > >
>> > > > Sergei
>> > > Does it matter if they differ if you cannot recreate the correct one
>> exactly from source-controllled DDL? Or know how they are supposed to
>> differ if this is a migration point?
>> >
>> >
>> > --
>> > Sent via pgsql-general mailing list
>> (pgsql-general(at)postgresql(dot)org)
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgsql-general
>>
>>
>> --
>> Bill Moran
>>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.