On Tue, Aug 2, 2011 at 5:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Phil Sorber <phil(at)omniti(dot)com> writes:
>> I have included two patches in this email. The first
>> (dump_user_config_last_with_set_role.patch) is an extension of my
>> first patch. In addition to moving the ALTER ROLE statements after the
>> CREATE ROLE statements it also inserts a SET ROLE after every connect.
>> It takes the role parameter from the --role command line option. This
>> fixes the problem of not being able to restore to a database because
>> of lack of permissions. This is similar to the idea proposed here:
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01046.php
>
> I don't understand why you think that that will fix anything?
>
> The problem that Florian originally pointed out is that settings
> established by ALTER DATABASE/ROLE could interfere with the restoration
> script's actions. That seems to be just as much of a risk for the
> --role role as the one originally used to connect. I don't see a way
> around that other than not applying those settings until we are done
> reconnecting to the target database.
>
> Also, given that the --role switch is only defined to select the role
> to be used at *dump* time, I'm unconvinced that forcing it to be used
> at *restore* time is a good idea. You'd really need to invent a
> separate switch if you were to go down this path.
>
> regards, tom lane
>
Ok, here is the patch that just moves the ALTER/SET pieces to the end.
Can we get this included in the next commit fest?