<p>On Oct 28, 2011 5:19 AM, "Bruce Momjian" <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>> wrote:<br />
><br/> > Stephen Frost wrote:<br /> ><br /> > > > > Regarding pg_dumpall and pg_restore, I'm
prettysure both of those can<br /> > > > > be configured to connect to other databases instead, including
for<br/> > > > > globals.<br /> > > ><br /> > > > Well, please show me the code, because
theC code I showed you had the<br /> > > > '\connect postgres' string hardcoded in there.<br /> > ><br
/>> > I guess there's a difference between "can be used and will work<br /> > > correctly, but might create
someextra garbage" and "can't be used at<br /> > > all". pg_dumpall has a -l option for connecting to whatever
*existing*<br/> > > database you have to pull the global data, and then it'll restore into a<br /> > >
cleaninitdb'd cluster, after which you could remove postgres.<br /> ><br /> > Keep in mind -l might connect to a
specifieddatabase to do the dump,<br /> > but it will still connect to the 'postgres' database to recreate them.<br
/>><br /> > > Admittedly, if you initdb the cluster, drop postgres, and then try a<br /> > > restore, it
wouldfail. Personally, I'm not a big fan of that (why<br /> ><br /> > Right, same with pg_upgrade.<br /> ><br
/>> > don't we use what was passed in to -l for that..?), but, practically,<br /> ><br /> > No
idea.<p>Chicken/egg?If we did that, the pg_dumpall dump could no longer be loaded into an empty cluster since the db it
wantedto talk to didn't exist yet. And restoring into an empty cluster has to be the main use for pg_dumpall after
all....<p>/Magnus
