On Fri, Nov 13, 2009 at 10:39 AM, Heikki Linnakangas
wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>>> I think it would be over the top to suggest that pg_dump has to cope
>>> with modifications that can only occur through manual updates to the
>>> system catalogs, but it seems like anything th
Tom Lane wrote:
It might be nice if manual changes to system objects got dumped,
but that's really an AI-complete problem --- which properties of
the objects represent manual changes, and how can we know whether
trying to apply those changes to a new system version will work?
A diff against te
Tom Lane wrote:
> Robert Haas writes:
>> I think it would be over the top to suggest that pg_dump has to cope
>> with modifications that can only occur through manual updates to the
>> system catalogs, but it seems like anything that can be done using DDL
>> statements should be handled.
>
> Like
Robert Haas writes:
> I think it would be over the top to suggest that pg_dump has to cope
> with modifications that can only occur through manual updates to the
> system catalogs, but it seems like anything that can be done using DDL
> statements should be handled.
Like, say, DELETE FROM pg_proc
On Fri, Nov 13, 2009 at 1:13 AM, Tom Lane wrote:
> "Robert Haas" writes:
>> The following command does not change the output of "pg_dumpall":
>> alter tablespace pg_default owner to bob;
>
> I don't think this is a bug. It's one specific aspect of a general
> principle that system objects don't
"Robert Haas" writes:
> The following command does not change the output of "pg_dumpall":
> alter tablespace pg_default owner to bob;
I don't think this is a bug. It's one specific aspect of a general
principle that system objects don't get dumped. If they did, using
pg_dump to upgrade across m
The following bug has been logged online:
Bug reference: 5184
Logged by: Robert Haas
Email address: robertmh...@gmail.com
PostgreSQL version: CVS HEAD
Operating system: Linux
Description:default tablespace owner is not dumped
Details:
The following command does not
