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?