On 5/11/21 11:11 AM, Bruce Momjian wrote:
> 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 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.
> but I was able to show it using attribute numbers, as you explained:
Yes, that was what the patch fixed.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development