From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: REFERENCES privilege should not be symmetric (was Re: [GENERAL] Postgres Permissions Article) |
Date: | 2017-03-31 15:29:24 |
Message-ID: | 3733.1490974164@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> In short, it seems like this statement in the docs is correctly describing
>> our code's behavior, but said behavior is wrong and should be changed.
>> I'd propose fixing it like that in HEAD; I'm not sure if the back branches
>> should also be changed.
> Sounds reasonable, but I don't see much advantage to changing it in
> the back-branches.
Well, it's a SQL-compliance bug, and we often back-patch bug fixes.
The argument for not back-patching a bug fix usually boils down to
fear of breaking existing applications, but it's hard to see how
removal of a permission check could break a working application ---
especially when the permission check is as hard to trigger as this one.
How many table owners ever revoke their own REFERENCES permission?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2017-03-31 16:00:20 | Re: Debian Bug#859033: pg_dump: creates dumps that cannot be restored |
Previous Message | Thorsten Glaser | 2017-03-31 15:21:40 | Re: Debian Bug#859033: pg_dump: creates dumps that cannot be restored |
From | Date | Subject | |
---|---|---|---|
Next Message | Keith Fiske | 2017-03-31 15:30:56 | pg_partman 3.0.0 - real-world usage of native partitioning and a case for native default |
Previous Message | David Rowley | 2017-03-31 15:25:12 | Re: multivariate statistics (v25) |