Robert Haas wrote:
> >> > If nobody objects, I'll go do that. ?Hopefully that should be enough
> >> > to put this problem to bed more or less permanently.
> >>
> >> All right, I've worked up a (rather boring and tedious) patch to do
> >> this, which is attached.
> >
> > I wonder if we should bother using a flag for this. ?No one has asked
> > for one, and the new code to conditionally connect to databases should
> > function fine for most use cases.
>
> True, but OTOH we have such a flag for pg_dumpall, and I've already
> done the work.
Well, every user-visible API option has a cost, and I am not sure there
is enough usefulness to overcome the cost of this.
As far as pg_dumpall, you could argue that the -l flag isn't needed;
the docs say:
-l dbname, --database=dbname
Specifies the name of the database to connect to to
dump global objects and discover what other databases
should be dumped. If not specified, the postgres
database will be used, and if that does not exist,
template1 will be used.
What is the value of this flag? The only value I can see would be if
the 'postgres' database does not exist and you are concerned that you
might block create database operations during pg_dumpall's dump of
global objects, or you don't have permissions for template1 for some
reason.
Also, if we are going to add this flag, we should have pg_dumpall use it
too and just depricate the old options.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
