On Fri, Sep 6, 2019 at 12:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Langote <amitlangot...@gmail.com> writes: > > On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > >> Instead of falling back to the child, isn't it make more sense to > >> check the permissions on the parent upto which we could translate (it > >> may not be the root parent)? > > > Hmm, in that case, the parent up to which we might be able to > > translate would still be a child and might have different permissions > > than the table mentioned in the query (what's being called "root" in > > this context). Would it be worth further complicating this code if > > that's the case? > > I think that checking intermediate levels would be an actively bad idea > --- it would make the behavior too confusing. We should preferably check > the table actually named in the query, or if we can't then check the > table we are using the stats of; nothing else.
Agreed. > Another idea that we should consider, though, is to allow the access if > *either* of those two tables allows it. The main reason that that's > attractive is that it's certain not to break any case that works today. > But also, it would mean that in many practical cases we'd not have to > try to map Vars back up to the original parent, thus avoiding the > performance penalty. (That is, check the target table as we do now, > and only if we find it lacks permissions do we start mapping back.) Ah, that sounds like a good idea. Patch updated that way. Thanks, Amit
v5-0001-Use-root-parent-s-permissions-when-reading-child-.patch
Description: Binary data
