Skip site navigation (1) Skip section navigation (2)

Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c
Date: 2011-10-12 19:48:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Oct 12, 2011 at 2:27 PM, Phil Sorber <phil(at)omniti(dot)com> wrote:
> I am going to remove that patch from the commit fest because we all
> agree that it does not solve the problem satisfactorily. I would like
> to re-iterate a few points, and submit a new patch.
> First off, there are two distinct problems here that we have been
> lumping into one. There is the issue of the 'ALTER DATABASE SET ROLE'
> and then there is the 'ALTER ROLE SET ROLE' case. The former is the
> one that has been causing us so many problems, and the latter is the
> one that I really care about.
> Also, there are more people that are hitting this issue as well:
> My proposal would be to table the discussion about the 'ALTER DATABASE
> SET ROLE' case because there seems to be a bit of a philosophical
> debate behind this that needs to be sorted out first.
> If we focus only on the 'ALTER ROLE' case I think there is a trivial
> solution. We already separate the CREATE from the ALTER in a single
> loop. We also already separate out the user config in a separate
> function called from this same loop. The problem is that the user
> config can be dependent upon a later CREATE. So all I suggest is to
> move the user config dumping into a new loop afterward so that the
> user config ALTER's come after all the other CREATE's and ALTER's. It
> amounts to a 7 line change and solves our problem rather elegantly.

I'm not sure I completely follow this explanation of the problem, but
it does seem better to me to set all the role attributes after dumping
all the create role statements, and I don't see how that can break
anything that works now.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-10-12 20:21:41
Subject: Re: Dumping roles improvements?
Previous:From: Andrew DunstanDate: 2011-10-12 19:33:28
Subject: Re: Dumping roles improvements?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group