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

On Tue, May 11, 2021 at 06:57:19AM -0400, Joe Conway wrote:
> On 5/10/21 9:56 PM, Bruce Momjian wrote:
> > On Mon, May 10, 2021 at 07:50:14AM -0400, Joe Conway wrote:
> > > On 5/10/21 2:03 AM, Bruce Momjian wrote:
> > > > I have committed the first draft of the PG 14 release notes.  You can
> > > > see the most current  build of them here:
> > > > >     https://momjian.us/pgsql_docs/release-14.html
> > > > > I need clarification on many items, and the document still needs
> > > its
> > > > items properly ordered, and markup added.  I also expect a lot of
> > > > feedback.
> > > > > I plan to work on completing this document this coming week in
> > > > preparation for beta next week.
> > > 
> > > While only a small change, this commit does affect user visible behavior and
> > > so should probably be noted:
> > > 
> > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b12bd4869b5e
> > 
> > I see your point.  Here is the release entry I added:
> 
> Not quite -- maybe something like the below:
> 
> >     <para>
> >     Return false for has_column_privilege() checks on non-existent or dropped columns (Joe Conway)
> 
> Always return NULL for has_column_privilege() checks on non-existent or
> dropped column by attnum (Joe Conway)
> 
> >     <para>
> >     Previously such columns returned an invalid column error.
> 
> 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 CURRENT_USER;
     current_user
    --------------
     postgres
    (1 row)

    test=> CREATE TABLE test (x int, y int);
    CREATE TABLE
    
    test=> CREATE USER test;
    CREATE ROLE
    
    test=> \c test test
    You are now connected to database "test" as user "test".
    
    test=> SELECT has_column_privilege('test', 'x', 'SELECT');
     has_column_privilege
    ----------------------
     f

    test=> SELECT has_column_privilege('test', 'z', 'SELECT');
    ERROR:  column "z" of relation "test" does not exist

but I was able to show it using attribute numbers, as you explained:

    test=> SELECT has_column_privilege('test', 1::smallint, 'SELECT');
     has_column_privilege
    ----------------------
     f
    (1 row)
    
    test=> SELECT has_column_privilege('test', 2::smallint, 'SELECT');
     has_column_privilege
    ----------------------
     f
    (1 row)
    
    test=> SELECT has_column_privilege('test', 3::smallint, 'SELECT');
     has_column_privilege
    ----------------------
    
    (1 row)

What is the logic that attribute numbers should behave differently than
attribute names?

Here is the updated text:

    <listitem>
    <!--
    Author: Joe Conway <mail@joeconway.com>
    2021-03-31 [b12bd4869] Fix has_column_privilege function corner case
    -->
    
    <para>
    Return false for has_column_privilege() checks on non-existent or
    dropped columns when using attribute numbers (Joe Conway)
    </para>
    
    <para>
    Previously such attribute numbers returned an invalid column error.
    </para>
    </listitem>
    
-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.