Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Date
Msg-id 2427.1516318541@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall
Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall
List pgsql-hackers
I wrote:
> What I think we should do for the time being is to have pg_dump treat
> database tablespace as a property it can't adjust after creation, just
> as it can't adjust locale or encoding.  That's a loss of functionality
> for pg_dumpall/pg_upgrade compared to where we are today, in that if
> you've set up the template1 or postgres DBs with nondefault tablespace
> then that won't propagate to the new cluster.  But the same can already
> be said about their locale and encoding, and I find it hard to believe
> that many people are trying to give those two DBs tablespace settings
> different from the cluster default, anyway.

Hm ... actually, there is more than one way to skin this cat.

Let me offer a modest proposal: pg_dumpall/pg_upgrade should simply DROP
postgres and template1 in the target cluster, and then re-create them
(from template0 of course).  With that, we'd not only cope with preserving
their tablespace settings, but we'd gain the ability to preserve their
locale and encoding, even if the target cluster had been initialized with
some other default.

If we did it like that, the rationale for an actual --set-db-properties
switch would vanish, at least so far as pg_dumpall is concerned -- we
could just make all that behavior an integral part of --create.  And
this wouldn't need to be conditional on getting ALTER DATABASE
CURRENT_DATABASE done.

Comments?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Next
From: Tom Lane
Date:
Subject: Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist