On 5/11/21 1:30 PM, Bruce Momjian wrote:
> On Tue, May 11, 2021 at 12:31:01PM -0400, Joe Conway wrote:
>> 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 ;-)
>
> It just feels like this change makes the function's behavior less
> consistent.
See Tom's commit message here:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3d0f68dd30612
In particular:
"The variants of these functions that take
numeric inputs (OIDs or column numbers) are
supposed to return NULL rather than failing
on bad input; this rule reduces problems with
snapshot skew when queries apply the functions
to all rows of a catalog."
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
