> I don't think there's any line near pg_dumpall. That tool seems to > have grown out of desperation without much actual design. I think it > makes more sense to plan around that's the best pg_dump behavior for the > various use cases.
Ok. > I like Noah's proposal of having pg_dump --create reproduce all > database-level state. Should it be enabled by default? If so, then wouldn't it make more sense to call it --no-create and do the opposite? So, --no-create would exclude rather than include database-level information? Would enabling it by default cause issues with the current expected use of the tool by end users? How would this handle related global objects? It seems like this part could get a little tricky. Taking it one step further, would a --all option that dumps all databases make sense as well? Of course I know that's probably a considerable undertaking and certainly beyond the current scope. Though, I thought I'd throw it out there. Also, I think this would potentially conflict with what FabrÃzio is doing with CURRENT_DATABASE on COMMENT, though, I think it might be a preferable solution. https://commitfest.postgresql.org/5/229/ -Adam -- Adam Brightwell - adam.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
