On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote:
> 2021年1月28日(木) 17:18 Peter Eisentraut:
> I'm not convinced the current behavior is wrong. Is there some
> practical use case that is affected by this behavior?
>
>
> I was poking around at the function with a view to using it for something and was
> curious what it did with bad input.
>
> Providing the column name of a dropped column:
>
> Me: "Hey Postgres, do I have privileges on the dropped column 'bar' of my
> table 'foo'?"
> Pg: "That column doesn't even exist - here, have an error instead."
> Me: "Hey Postgres, does some other less-privileged user have privileges on the
> dropped column 'bar' of my table 'foo'?
> Pg: "That column doesn't even exist - here, have an error instead."
>
> Providing the attnum of a dropped column:
>
> Me: "Hey Postgres, here's the attnum of the dropped column 'bar', does some
> other less-privileged user have privileges on that column?"
> Pg: "That column doesn't even exist - here, have a NULL".
> Me: "Hey Postgres, here's the attnum of the dropped column 'bar' on this table
> I own, do I have privileges on that column?"
> Pg: "Yup. And feel free to throw any other smallint at me, I'll pretend that
> represents a column too even if it never existed.".
>
> Looking at the code, particularly the cited comment, it does seems the intent was
> to return NULL in all cases where an invalid attnum was provided, but that gets
> short-circuited by the assumption table owner = has privilege on any column.
Nicely illustrated :-)
> Not the most urgent or exciting of issues, but seems inconsistent to me.
+1
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
