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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers