Michael, * Michael Paquier (michael.paqu...@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
signature.asc
Description: Digital signature
