Re: PG 14 release notes, first draft - Mailing list pgsql-hackers

From Joe Conway
Subject Re: PG 14 release notes, first draft
Date
Msg-id bb7ce6aa-ef16-7725-c742-9edb5ac2dacb@joeconway.com
Whole thread Raw
In response to Re: PG 14 release notes, first draft  (Bruce Momjian <bruce@momjian.us>)
Responses Re: PG 14 release notes, first draft
List 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



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Parallel INSERT SELECT take 2
Next
From: Andres Freund
Date:
Subject: Re: seawasp failing, maybe in glibc allocator