Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> 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?
>
> Well, it'll have to fail for the name case, but not for the attnum case.
Why?
> > 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.
>
> You can't have it both ways. Either you throw an error if the name's
> not there, or you don't.
I'm not following why we couldn't handle a dropped column differently.
Dropped tables don't hang around in the catalog long after they've been
dropped.
> > In particular, I can see this function being used in
> > a where clause across pg_attribute.
>
> As said above, it can work as long as you use attnum not attname.
> I don't think this is really so different from iterating across
> pg_class (or any other catalog) and passing relname instead of OID.
If you really insist that we not do something better when it comes to
dropped columns then I'll drop my argument, but I do see dropped columns
as a materially different thing from dropped tables because of how we
keep them around in the catalog.
Thanks!
Stephen
