On 03/05/10 01:30, Tom Lane wrote:
> Russell Smith <mr-russ(at)pws(dot)com(dot)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:
> (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
I will leave it there on the basis of the TODO item and previous
In response to
pgsql-bugs by date
|Next:||From: Russell Smith||Date: 2010-05-12 09:57:41|
|Subject: pg_restore ignores -C when using a restore list -L|
|Previous:||From: Andres Freund||Date: 2010-05-12 08:30:52|
|Subject: Re: BUG #5459: Unable to cancel query while in send()|