Re: pg_dump --split patch
Dimitri Fontaine <dimitri@2ndquadrant.fr>
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Marko Tiikkaja <pgmail@joh.to>
Cc: Joel Jacobson <joel@gluefinance.com>, pgsql-hackers@postgresql.org
Date: 2012-11-16T14:52:53Z
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
Hi, Marko Tiikkaja <pgmail@joh.to> writes: > The general output scheme looks like this: > schemaname/OBJECT_TYPES/object_name.sql, I like this feature, I actually did have to code it myself in the past and several other people did so, so we already have at least 3 copies of `getddl` variants around. I really think this feature should be shipped by default with PostgreSQL. I don't much care for the all uppercase formating of object type directories in your patch though. > Overloaded functions are dumped into the same file. Object names are > encoded into the POSIX Portable Filename Character Set ([a-z0-9._-]) by > replacing any characters outside that set with an underscore. What happens if you have a table foo and another table "FoO"? > Restoring the dump is supported through an index.sql file containing > statements which include (through \i) the actual object files in the dump > directory. I think we should be using \ir now that we have that. > Any thoughts? Objections on the idea or the implementation? As far as the implementation goes, someone with more experience on the Archiver Handles should have a look. To me, it looks like you are trying to shoehorn your feature in the current API and that doesn't feel good. The holly grail here that we've been speaking about in the past would be to separate out tooling and formats so that we have: pg_dump | pg_restore pg_export | psql In that case we would almost certainly need libpgdump to share the code, and we maybe could implement a binary output option for pg_dump too (yeah, last time it was proposed we ended up with bytea_output = 'hex'). That libpgdump idea basically means we won't have the --split feature in 9.3, and that's really bad, as we already are some releases late on delivering that, in my opinion. Maybe the pg_export and pg_dump tool could share code by just #include magic rather than a full blown lib in a first incantation? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support