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.
> This is the code comment that predates the patch but is the reason behind
> the change:
>
> ------------
> /*
> * has_any_column_privilege variants
> * These are all named "has_any_column_privilege" at the SQL level.
> * They take various combinations of relation name, relation OID,
> * user name, user OID, or implicit user = current_user.
> *
> * The result is a boolean value: true if user has the indicated
> * privilege for any column of the table, false if not. The variants
> * that take a relation OID return NULL if the OID doesn't exist.
> */
> ------------
>
> The patch made that last sentence true in the corner cases.
Well, the example I showed was for attribute numbers but relation names,
which isn't mentioned in this comment.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.