On Sun, 17 Apr 2016 14:10:50 -0600 Sergei Agalakov <Sergei.Agalakov@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Bill Moran -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
