Michael,
* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Tue, Dec 26, 2017 at 02:15:18PM -0500, Peter Eisentraut wrote:
> > On 12/20/17 22:01, Stephen Frost wrote:
> > > There's some downsides to this approach though: we do an initial set of
> > > checks in ExecGrantStmt, but we can't do all of them because we don't
> > > know if it's a sequence or not, so we end up with some additional
> > > special checks to see if the GRANT is valid down in ExecGrant_Relation
> > > after we figure out what kind of relation it is.
> >
> > I think that we allow a sequence to be treated like a table in GRANT
> > (and other places) is a historical wart that we won't easily be able to
> > get rid of. I don't think the object address system should be bent to
> > accommodate that. I'd rather see the warts in the code explicitly.
>
> Yes, I agree with that. GRANT without an object defined works fine for
> sequences, so you want to keep an abstraction level where a relation
> means more than a simple table.
I'm not sure that I agree that this is really an 'abstraction' in this
instance- it's not like we can keep considering the object passed in a
generic 'relation' in the GRANT case throughout, instead we end up
having to run down what it is later on to make sure that the GRANT
command is valid, so it's really just that it's ambiguous at parse time
and we don't try to resolve it right away to exactly what it is until we
get a bit farther along.
We could certainly just run down what it is right after the
RangeVarGetRelId(), or have cases in the switch statements in
objectNamesToOids() and ExecGrantStmt_oids() that handle a case where
the object type isn't known yet and then do some kind of lookup to
figure out what kind of object it actually is. It'd be nice to only do
that lookup once (which is how things work today), but, as I mentioned
up-thread, that would require moving more things down (not that I think
that's really a bad thing...).
Thanks!
Stephen