Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> But it's not quite clear to me what we want the behavior for bad column
> >> name to be. A case could be made for either of:
> >>
> >> * If either the table OID is bad, or the OID is OK but there's no such
> >> column, return null.
> >>
> >> * Return null for bad OID, but if it's OK, continue to throw error
> >> for bad column name.
> >>
> >> The second case seems weirdly inconsistent, but it might actually
> >> be the most useful definition. Not detecting a misspelled column
> >> name is likely to draw complaints.
> >>
> >> Thoughts?
>
> > What are we going to do for dropped columns..? Seems like with what
> > you're suggesting we'd throw an error, but that'd make querying with
> > this function similairly annoying at times.
>
> True, but I think dropping individual columns is much less common
> than dropping whole tables.

That certainly doesn't mean that it doesn't happen though, nor does it
mean we don't have to come up with an answer to the question.

> The general plan in the has_foo_privilege functions is to throw errors for
> failing name-based lookups, but return null for failing numerically-based
> lookups (object OID or column number). I'm inclined to think we should
> stick to that. In the case at hand, we'd be supporting queries that
> iterate over pg_attribute, but they'd have to pass attnum not attname
> to avoid snapshot-skew failures. That's a bit annoying, but not throwing
> error for a typo'ed name is annoying to a different and probably larger
> set of users.

... and what's going to happen when they pass in a dropped column,
either via number or name?

I don't have an issue with throwing a failure for name-based lookups but
returning null for failing numerically-based lookups, but I don't really
want us throwing errors on dropped columns. I would think we'd return
null in that case. In particular, I can see this function being used in
a where clause across pg_attribute.

Thanks!

Stephen