Re: pg_dump --split patch
Joel Jacobson <joel@gluefinance.com>
From: Joel Jacobson <joel@gluefinance.com>
To: pgsql-hackers@postgresql.org
Date: 2010-12-28T16:41:04Z
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 →
-
pg_dump: Output functions deterministically sorted
- 7b583b20b1c9 9.3.0 cited
-
When sorting functions in pg_dump, break ties (same name) by number of arguments
- 1acc06a1f4ae 9.0.0 cited
2010/12/28 Tom Lane <tgl@sss.pgh.pa.us> > Joel Jacobson <joel@gluefinance.com> writes: > > Dear fellow hackers, > > Problem: A normal diff of two slightly different schema dump files > (pg_dump > > -s), will not produce a user-friendly diff, as you get all changes in the > > same file. > > > Solution: I propose a new option to pg_dump, --split, which dumps each > > object to a separate file in a user friendly directory structure: > > Um ... how does that solve the claimed problem exactly? > Because then you can do, $ diff -r <old schema dump dir> <new schema dump dir>, instead of, $ diff <old entire schema dump> <new entire schema dump> which will nicely reveal each individual object modified, as opposed to a huge global diff of everything > > > [-f filename] : main dump file, imports each splitted part using \i > > [-f filename]-split/[desc]/[tag]/[oid].sql : dump of the oid > > This particular choice seems remarkably *un* friendly, since two dumps > from different DBs will inevitably not share the same OIDs, making it > practically impossible to compare them even if they are logically > identical. But even without the choice to use OIDs in the filenames > I'm unconvinced that file-per-object is a good idea in any way shape or > form. > Good point! To compare two different database, perhaps it's possible to use a sequence, 1,2,...,n for each file in each directory, i.e., /[desc]/[tag]/[n], and to sort them by something distinct which will ensure the same numbering between different databases, such as the arguments for functions, or other properties for other kind of objects. Any ideas? (In my case, I didn't need to compare schemas between different database. I needed to compare two dumps created at different points in time of the same database, which do share the same oids for objects existing in both versions.) > > regards, tom lane > -- Best regards, Joel Jacobson Glue Finance E: jj@gluefinance.com T: +46 70 360 38 01 Postal address: Glue Finance AB Box 549 114 11 Stockholm Sweden Visiting address: Glue Finance AB Birger Jarlsgatan 14 114 34 Stockholm Sweden