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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c
Date: 2011-08-02 21:05:27
Message-ID: 29562.1312319127@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2011-08-02 23:52:17
Subject: Further news on Clang - spurious warnings
Previous:From: Kevin GrittnerDate: 2011-08-02 21:03:21
Subject: Re: Transient plans versus the SPI API

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