Re: "has_column_privilege()" issue with attnums and non-existent columns

On 2021-01-12 06:53, Ian Lawrence Barwick wrote:
>      postgres=# SELECT has_column_privilege('foo', 999::int2, 'SELECT');
>       has_column_privilege
>      ----------------------
>       t
>      (1 row)
> 
> The comment on the relevant code section in "src/backend/utils/adt/acl.c"
> (related to "column_privilege_check()") indicate that NULL is the intended
> return value in these cases:
> 
>       Likewise, the variants that take an integer attnum
>       return NULL (rather than throwing an error) if there is no such
>       pg_attribute entry.  All variants return NULL if an attisdropped
>       column is selected.
> 
> The unexpected "TRUE" value is a result of "column_privilege_check()" returning
> TRUE if the user has table-level privileges.  This returns a valid result with
> the function variants where the column name is specified, as the calling
> function will have already performed a check of the column through its call to
> "convert_column_name()".  However when the attnum is specified, the status of
> the column never gets checked.

I'm not convinced the current behavior is wrong.  Is there some 
practical use case that is affected by this behavior?

> The second patch adds a bunch of missing static prototypes to "acl.c",
> on general
> principles.

Why is this necessary?