Hi Dilip,
Thanks for checking.
On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Thu, Sep 5, 2019 at 2:12 PM Amit Langote <amitlangote09@gmail.com> wrote:
> Thanks for the patch, I was almost about to press the send button with
> my patch. But, this looks similar to my version.
Good to hear that.
> > On Wed, Sep 4, 2019 at 8:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > * I'd be inclined to use an actual test-and-elog not just an Assert
> > > for the no-mapping-found case. For one reason, some compilers are
> > > going to complain about a set-but-not-used variable in non-assert
> > > builds. More importantly, I'm not very convinced that it's impossible
> > > to hit the no-mapping case. The original proposal was to fall back
> > > to current behavior (test the child-table permissions) if we couldn't
> > > match the var to the top parent, and I think that that is still a
> > > sane proposal.
> >
> > OK, I've removed the Assert. For child Vars that can't be translated
> > to root parent's, permissions are checked with the child relation,
> > like before.
>
> 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?
Thanks,
Amit