Re: Misleading error "permission denied for table"

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Wed, Oct 16, 2024 at 07:36:29PM +0530, Ashutosh Bapat wrote:
>> Shouldn't we report "permission defined for column atest5.three?

> We do have "permission denied for column" messages in aclchk.c (e.g.,
> aclcheck_error_col()), but I don't see them actually used anywhere (or at
> least they don't show up in any expected regression test output). I'm
> inclined to agree that a more specific error would be nice, but I worry
> there's some hidden complexity that's prevented it thus far...

See ExecCheckOneRelPerms, which seems to regard this as a TODO.
I think the hard part is how to report the cases that involve
pg_attribute_aclcheck_all(..., ACLMASK_ANY), which means

* If 'how' is ACLMASK_ANY, then returns ACLCHECK_OK if user has any of the
* privileges identified by 'mode' on any non-dropped column in the relation;

so that you can't really finger a specific column as being in
violation. Maybe we could leave those cases as just mentioning the
rel; not sure if that leads to failing to move the goalposts much.
Otherwise, we could extend ExecCheckOneRelPerms and
pg_attribute_aclcheck_all to pass back a column number, and
then modify the error reporting in ExecCheckPermissions.

regards, tom lane