| From: | Florian Pflug <fgp(at)phlo(dot)org> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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: | 2010-12-13 01:21:00 |
| Message-ID: | 2628800C-D53C-4885-A089-C771A83E84BD@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Dec13, 2010, at 00:16 , Robert Haas wrote:
> And in fact it strikes me that we might not have much choice about how
> to fix this. I think we are not going to retroactively change the
> behavior of ALTER DATABASE .. SET ROLE in a released version, but yet
> we do, I think, want to make pg_upgrade work.
A simple fix is to teach pg_upgrade to issue "RESET SESSION AUTHORIZATION" immediately after connecting to a database. I don't see any downside of this currently - it seems that the only case where this wouldn't be a NO-OP is if someone set ROLE to to something else either per-database, per-user or both.
Actually, I'd like to provide an option for pg_dump and pg_restore to do that too (not by default, though). If people think this is a good idea, I could come up with a patch.
best regards,
Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rob Wultsch | 2010-12-13 01:27:51 | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED |
| Previous Message | Robert Haas | 2010-12-13 01:20:35 | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED |