From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG 14 release notes, first draft |
Date: | 2021-05-11 16:31:01 |
Message-ID: | bb7ce6aa-ef16-7725-c742-9edb5ac2dacb@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/11/21 11:37 AM, Bruce Momjian wrote:
> On Tue, May 11, 2021 at 11:26:48AM -0400, Joe Conway wrote:
>> On 5/11/21 11:11 AM, Bruce Momjian wrote:
>> > > Previously existence of such columns were ignored when caller had table
>> > > level privileges.
>> >
>> > I can't reproduce the NULL using column name text:
>>
>> > test=> SELECT has_column_privilege('test', 'z', 'SELECT');
>> > ERROR: column "z" of relation "test" does not exist
>>
>> That is the way it is supposed to work when the column is specified by name.
>> The patch did not change that in any way.
>
> I am just confused why attribute numbers are handled differently than
> attribute names.
I am not entirely sure, but that boat sailed a long time ago and really
has nothing to do with this patch ;-)
This is the code comment that predates the patch but is the reason
behind the change:
------------
/*
* has_any_column_privilege variants
* These are all named "has_any_column_privilege" at the SQL level.
* They take various combinations of relation name, relation OID,
* user name, user OID, or implicit user = current_user.
*
* The result is a boolean value: true if user has the indicated
* privilege for any column of the table, false if not. The variants
* that take a relation OID return NULL if the OID doesn't exist.
*/
------------
The patch made that last sentence true in the corner cases.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-05-11 17:13:42 | Re: seawasp failing, maybe in glibc allocator |
Previous Message | Bharath Rupireddy | 2021-05-11 16:15:12 | Re: Parallel INSERT SELECT take 2 |