Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1lgU2f-0001j4-1u
	for pgsql-hackers@arkaria.postgresql.org; Tue, 11 May 2021 15:11:25 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1lgU2d-0001AT-Tp
	for pgsql-hackers@arkaria.postgresql.org; Tue, 11 May 2021 15:11:23 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1lgU2d-0001A9-Lz
	for pgsql-hackers@lists.postgresql.org; Tue, 11 May 2021 15:11:23 +0000
Received: from momjian.us ([72.94.173.45])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1lgU2b-00034R-Bk
	for pgsql-hackers@postgresql.org; Tue, 11 May 2021 15:11:22 +0000
Received: from bruce by momjian.us with local (Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1lgU2a-0002GO-1t; Tue, 11 May 2021 11:11:20 -0400
Date: Tue, 11 May 2021 11:11:20 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Joe Conway <mail@joeconway.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PG 14 release notes, first draft
Message-ID: <20210511151120.GS6088@momjian.us>
References: <20210510060308.GC6088@momjian.us>
 <1ff33728-e912-2006-6864-c99abbc99603@joeconway.com>
 <20210511015645.GL6088@momjian.us>
 <e507bfe1-9d04-fae5-15eb-d1a1796de03d@joeconway.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e507bfe1-9d04-fae5-15eb-d1a1796de03d@joeconway.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/20210511151120.GS6088%40momjian.us>
Precedence: bulk

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.