On Wed, Oct 12, 2011 at 2:27 PM, Phil Sorber <p...@omniti.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: > > http://archives.postgresql.org/pgsql-hackers/2011-02/msg02362.php > > 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 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