On Mon, May 21, 2012 at 5:25 PM, Joel Jacobson <joel@trustly.com> wrote:
> If one want to reuse the splitting to files-code of the directory
> format, maybe the existing option -F d could be tweaked to output in
> both a a machine-readable format (current way), and also a
> human-friendly tree of files and content (like suggested by my patch).
>
> I wonder what the option would be called then, having two chars
> options is not an option I guess, maybe -F t for "tree" instead of
> "directory", as the -F d option only dumps to a single directory and
> not a tree-structure?
Is there a reason why the current directory format could not be
adjusted to become more human-readable friendly for mechanical
reasons? I realize there is a backwards compatibility problem, but it
may be better than bloating a new option.
Andrew's approach of reading the TOC also be good...as so pg_dump can
avoid serving the additional master of schema versioning and
development usability in addition to dumping. The TOC is the closest
thing we have to the library-ification of pg_dump in the near-term.
But I don't see how making the directory output format more
human-friendly could be seen as a bad thing overall, except in the
notable axis of implementation complexity. Silly issues like naming
files on different platforms, case sensitivity, and file length
restrictions may rear their ugly head.
I think about this because in addition to the data types and operators
defined in the development process, there are often small tables that
need to be loaded with content and version controlled as well, rather
like userland-equivalents pg_enum entries.
--
fdr