On 03/05/10 01:30, Tom Lane wrote: > Russell Smith <mr-r...@pws.com.au> writes: > >> On 02/05/10 01:36, Tom Lane wrote: >> >>> No, that's the intended place for them given the current division of >>> labor between pg_dump and pg_dumpall. There have been complaints before >>> about this, but no one has proposed a better approach (where better >>> means "fixes this without breaking use-cases that work now"). >>> > >> I have just spent an hour searching the archives and have been unable to >> find any discussions on this issue. I must be searching the wrong >> terms. Any ideas? I would like to discuss this further, but it's a >> little futile without reading the background material. >> > If you were looking specifically for mention of CONNECT privileges, you > likely wouldn't have found much, because that's a pretty new feature. > Most of the previous discussions have related to other database-level > attributes, such as ALTER DATABASE SET properties --- but it's basically > the same problem. A few minutes of searching turned up several threads: > > http://archives.postgresql.org/pgsql-hackers/2009-09/msg01944.php > http://archives.postgresql.org/pgsql-hackers/2006-10/msg00432.php > http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php > > (the last of these is actually a TODO entry) > > The TODO item covers my expected behaviour. If you create the database from scratch, you expect it to have all the alter commands, if you are restoring into in, you get what is already there.
Also you can pg_restore to a text file if you want those global parameters out and work with that. So the information is not lost if it's stored in the dump with the customer format. At the moment the information is lost at dump time. I think Richard in correct in the discussion that even though database information is stored globally, it's not global. If it was, pg_dumpall -g would dump it. It's certainly overly complex to get pg_dumpall to give you those database parameters. I will leave it there on the basis of the TODO item and previous discussions. Regards Russell -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
