Phil Sorber <p...@omniti.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
