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
