| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Florian Pflug <fgp(at)phlo(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |
| Date: | 2011-01-06 04:08:21 |
| Message-ID: | 24698.1294286901@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> I think pg_dumpall would have failed with this setup too, so I don't see
>> this as a pg_upgrade bug, nor something that I am willing to risk adding
>> to pg_upgrade.
> If adding RESET SESSION AUTHORIZATION fixes the bug, I think we should
> consider doing that.
I think an appropriate response would be to prevent ALTER DATABASE SET
ROLE. I really cannot believe that there are any situations where
that's a good idea.
Or we could take the approach somebody was just espousing about
> Our job is to prevent the user from *accidentally*
> shooting themselves in the foot.
If they want to deliberately shoot themselves in the foot by hosing the
login system like that, it's not our job to prevent it. But it's not
our job to try to work around it, either.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2011-01-06 04:10:02 | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |
| Previous Message | Bruce Momjian | 2011-01-06 03:13:59 | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |