Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces

Florian Pflug wrote:
> On Oct27, 2011, at 23:02 , Bruce Momjian wrote:
> > Florian Pflug wrote:
> >> On Oct21, 2011, at 16:42 , Phil Sorber wrote:
> >>> If you did want to make them immutable, I also like Florian's idea of
> >>> a dependency graph. This would make the dumps less readable though.
> >> 
> >> Hm, I kinda reversed my opinion on that, though - i.e., I no longer think
> >> that the dependency graph idea has much merit. For two reasons
> >> 
> >> First, dependencies work on OIDs, not on names. Thus, for the dependency
> >> machinery to work for GUCs, they'd also need to store OIDs instead of
> >> names of referenced schema objects. (Otherwise you get into trouble if
> >> objects are renamed)
> >> 
> >> Which of course doesn't work, at least for roles, because roles are
> >> shared objects, but referenced objects might be database-local.
> >> (search_path, for example).
> > 
> > Is this a TODO?
> 
> The idea quoted above, no. But
> 
>  Downgrade non-immutable (i.e., dependent on database state) checks during
>  "ALTER ROLE/DATABASE SET" to WARNINGs to avoid breakage during restore
> 
> makes for a fine TODO, I'd say.

Well, psql currently ignored restore errors too, so I am not sure what
the value of this is, except that pg_upgrade will not error exit, but I
am not sure that is a good idea here either.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +