Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: has_column_privilege behavior (was Re: Assert failed insnprintf.c)
Date
Msg-id 20181001190553.GF4184@tamriel.snowman.net
Whole thread Raw
In response to Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.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

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: executor relation handling
Next
From: Tom Lane
Date:
Subject: Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)