On Wed, Jul 22, 2015 at 3:42 PM, Adam Brightwell <adam.brightw...@crunchydatasolutions.com> wrote: >> 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?
This seems a bit hairy to me. If we want to transfer responsibility for dumping this stuff from pg_dumpall to pg_dump, I have no problem with that at all. But doing it only when --create is specified seems odd. Then, does pg_dumpall -g dump it or not? If it does, then we're sorta dumping it in two places when --create is used. If it doesn't, then when --create is not used we're doing it nowhere. I may be confused. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
