On Mon, Oct 10, 2011 at 12:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I don't really >> understand why it's not OK to just have pg_dump issue RESET ROLE at >> appropriate points in the process; that seems like it would be >> sufficient and not particularly ugly. > > Well, it was alleged that that would fix this problem: > http://archives.postgresql.org/pgsql-hackers/2010-12/msg00916.php > but if it does fix it, I think that's a bug in itself: > http://archives.postgresql.org/pgsql-hackers/2010-12/msg01031.php
Hmm. > But more to the point, I think the specific case of "ALTER DATABASE SET > ROLE" is just one element of a class of problems, namely that settings > attached to either databases or roles could create issues for restoring > a dump. Issuing RESET ROLE would fix only that one single case. It's not very clear to me that we're going to find a fix that reaches across every setting, though. I mean, for something like maintenance_work_mem, there's no correctness issue regardless of when the new setting takes effect, but there might very well be a performance issue, and it's not really all that clear when the "right" time to put the old setting back is. And that ambiguity about what's actually correct is, perhaps, the root of the problem. There are related cases where we have a clear-cut policy. For example, we are clear that you must use the newer pg_dump against the older server for best results. That's not always convenient, but at least it's a line in the sand. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers