| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: role self-revocation |
| Date: | 2022-03-07 18:52:41 |
| Message-ID: | 210080.1646679161@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Agreed, this is not something to move on quickly. We might want
>> to think about adjusting pg_dump to use explicit GRANTED BY
>> options in GRANT/REVOKE a release or two before making incompatible
>> changes.
> I'm with Robert on this though- folks should know already that they need
> to use the pg_dump of the version of PG that they want to move to and
> not try to re-use older pg_dump output with newer versions, for a number
> of reasons and this is just another.
Yeah, in an ideal world you'd do that, but our users don't always have
the luxury of living in an ideal world. Sometimes all you've got is
an old pg_dump file. Perhaps this behavior wouldn't mess things up
enough to make the restored database unusable, but we need to think
about (and test) that case while we're considering changes.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-03-07 18:58:22 | Re: role self-revocation |
| Previous Message | Stephen Frost | 2022-03-07 18:49:43 | Re: role self-revocation |