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:
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
In response to
pgsql-hackers by date
|Next:||From: Peter Geoghegan||Date: 2011-08-02 23:52:17|
|Subject: Further news on Clang - spurious warnings|
|Previous:||From: Kevin Grittner||Date: 2011-08-02 21:03:21|
|Subject: Re: Transient plans versus the SPI API|