On Wed, Nov 27, 2019 at 3:25 AM Tom Lane wrote:
> Amit Langote writes:
> > If inh_root_relid meant that, it would no longer be useful to
> > examine_variable. In examine_variable, we need to map a child table's
> > relid to the relid of its root parent table. If the root parent
> > itself is
Amit Langote writes:
> On Thu, Nov 21, 2019 at 6:34 AM Tom Lane wrote:
>> The comment for inh_root_relid seems rather inadequate, since it
>> fails to mention the special case for UNION ALL subqueries.
>> But do we even need that special case? It looks to me like the
>> walk-up-to-parent code
Thanks for the review.
On Thu, Nov 21, 2019 at 6:34 AM Tom Lane wrote:
>
> Amit Langote writes:
> > [ v6-0001-Use-root-parent-s-permissions-when-reading-child-.patch ]
>
> I started to review this, and discovered that the new regression test
> passes just fine without applying any of the rest
Amit Langote writes:
> [ v6-0001-Use-root-parent-s-permissions-when-reading-child-.patch ]
I started to review this, and discovered that the new regression test
passes just fine without applying any of the rest of the patch.
Usually we try to design regression test additions so that they
On Thu, Sep 26, 2019 at 5:15 AM Alvaro Herrera wrote:
> Travis complains that this patch adds a new compile warning. Please
> fix.
Thanks, updated patch attached.
Regards,
Amit
v6-0001-Use-root-parent-s-permissions-when-reading-child-.patch
Description: Binary data
Travis complains that this patch adds a new compile warning. Please
fix.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Sep 6, 2019 at 12:53 AM Tom Lane wrote:
>
> Amit Langote writes:
> > On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar 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
Amit Langote writes:
> On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar 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
On Thu, Sep 5, 2019 at 3:26 PM Amit Langote wrote:
>
> On Thu, Sep 5, 2019 at 6:33 PM Dilip Kumar wrote:
> > /*
> > + * For inheritance child relations, we also need to remember
> > + * the root parent.
> > + */
> > + if (parent->rtekind == RTE_RELATION)
> > + rel->inh_root_relid =
On Thu, Sep 5, 2019 at 6:33 PM Dilip Kumar wrote:
> /*
> + * For inheritance child relations, we also need to remember
> + * the root parent.
> + */
> + if (parent->rtekind == RTE_RELATION)
> + rel->inh_root_relid = parent->inh_root_relid > 0 ?
> + parent->inh_root_relid :
> + parent->relid;
>
On Wed, Sep 4, 2019 at 8:53 AM Tom Lane wrote:
>
> Amit Langote writes:
> > [ v2-0001-Use-root-parent-s-permissions-when-read-child-tab.patch ]
>
> I took a quick look through this. I have some cosmetic thoughts and
> also a couple of substantive concerns:
Thanks a lot for reviewing this.
> *
Hi Dilip,
Thanks for checking.
On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar wrote:
> On Thu, Sep 5, 2019 at 2:12 PM Amit Langote 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,
On Thu, Sep 5, 2019 at 2:48 PM Dilip Kumar wrote:
>
> On Thu, Sep 5, 2019 at 2:12 PM Amit Langote wrote:
>
> Thanks for the patch, I was almost about to press the send button with
> my patch. But, this looks similar to my version.
> >
> > On Wed, Sep 4, 2019 at 8:53 AM Tom Lane wrote:
>
>
On Thu, Sep 5, 2019 at 2:12 PM Amit Langote wrote:
Thanks for the patch, I was almost about to press the send button with
my patch. But, this looks similar to my version.
>
> On Wed, Sep 4, 2019 at 8:53 AM Tom Lane wrote:
> >
> > Amit Langote writes:
> > > [
Amit Langote writes:
> [ v2-0001-Use-root-parent-s-permissions-when-read-child-tab.patch ]
I took a quick look through this. I have some cosmetic thoughts and
also a couple of substantive concerns:
* As a rule, patches that add fields at the end of a struct are wrong.
There is almost always
On Mon, Jul 29, 2019 at 6:59 PM Dilip Kumar wrote:
> On Wed, Jul 17, 2019 at 2:39 PM Amit Langote wrote:
> > I've combined the two patches into one.
> Looks fine to me, moved to ready for committer.
Thank you Dilip.
Regards,
Amit
On Wed, Jul 17, 2019 at 2:39 PM Amit Langote wrote:
>
> On Wed, Jul 10, 2019 at 2:43 PM Dilip Kumar wrote:
> > On Wed, Jul 10, 2019 at 10:15 AM Amit Langote
> > wrote:
> > > Thanks for checking. There has been a lot of churn in the inheritance
> > > planning code since my last email on this
On Wed, Jul 10, 2019 at 2:43 PM Dilip Kumar wrote:
> On Wed, Jul 10, 2019 at 10:15 AM Amit Langote wrote:
> > Thanks for checking. There has been a lot of churn in the inheritance
> > planning code since my last email on this thread, so I'd like to
> > reconsider. I'm busy this week with some
On Wed, Jul 10, 2019 at 10:15 AM Amit Langote wrote:
>
> Hi Dilip,
>
> On Wed, Jul 10, 2019 at 1:29 PM Dilip Kumar wrote:
> > On Wed, Jul 10, 2019 at 9:44 AM Dilip Kumar wrote:
> > > On Fri, Nov 2, 2018 at 1:34 PM Amit Langote wrote:
> > > > Okay, here are two patches:
> > > >
> > > > 0001 adds
Hi Dilip,
On Wed, Jul 10, 2019 at 1:29 PM Dilip Kumar wrote:
> On Wed, Jul 10, 2019 at 9:44 AM Dilip Kumar wrote:
> > On Fri, Nov 2, 2018 at 1:34 PM Amit Langote wrote:
> > > Okay, here are two patches:
> > >
> > > 0001 adds a new RelOptInfo member inh_root_parent that's set for
> > >
On Wed, Jul 10, 2019 at 9:44 AM Dilip Kumar wrote:
>
> On Fri, Nov 2, 2018 at 1:34 PM Amit Langote
> wrote:
> >
> > On 2018/11/01 20:34, Dilip Kumar wrote:
> > > On Mon, Oct 29, 2018 at 2:53 PM Amit Langote wrote:
> > >> Anyway, why don't we just use the child table's AppendRelInfo to get the
>
On Fri, Nov 2, 2018 at 1:34 PM Amit Langote
wrote:
>
> On 2018/11/01 20:34, Dilip Kumar wrote:
> > On Mon, Oct 29, 2018 at 2:53 PM Amit Langote wrote:
> >> Anyway, why don't we just use the child table's AppendRelInfo to get the
> >> parent's version of varattno instead of creating a new
On 2018/11/01 20:34, Dilip Kumar wrote:
> On Mon, Oct 29, 2018 at 2:53 PM Amit Langote wrote:
>> Anyway, why don't we just use the child table's AppendRelInfo to get the
>> parent's version of varattno instead of creating a new function? It can
>> be done as shown in the attached revised version
On Mon, Oct 29, 2018 at 2:53 PM Amit Langote
wrote:
>
> Thank you for creating the patch.
>
> On 2018/10/28 20:35, Dilip Kumar wrote:
> > On Sat, Oct 27, 2018 at 10:07 AM Dilip Kumar wrote:
> >> On Fri, Oct 26, 2018 at 1:12 PM Amit Langote wrote:
> >>> On 2018/10/25 19:54, Dilip Kumar wrote:
>
Thank you for creating the patch.
On 2018/10/28 20:35, Dilip Kumar wrote:
> On Sat, Oct 27, 2018 at 10:07 AM Dilip Kumar wrote:
>> On Fri, Oct 26, 2018 at 1:12 PM Amit Langote wrote:
>>> On 2018/10/25 19:54, Dilip Kumar wrote:
Basically, if the relation is RELOPT_OTHER_MEMBER_REL, we can
On Sat, Oct 27, 2018 at 10:07 AM Dilip Kumar wrote:
>
> On Fri, Oct 26, 2018 at 1:12 PM Amit Langote
> wrote:
> >
> > On 2018/10/25 19:54, Dilip Kumar wrote:
> > > On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote:
> > >> Amit Langote writes:
> > >>> But maybe for the case under question, that's
On Fri, Oct 26, 2018 at 1:12 PM Amit Langote
wrote:
>
> On 2018/10/25 19:54, Dilip Kumar wrote:
> > On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote:
> >> Amit Langote writes:
> >>> But maybe for the case under question, that's irrelevant, because
> >>> we're only interested in access to
On 2018/10/25 19:54, Dilip Kumar wrote:
> On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote:
>> Amit Langote writes:
>>> But maybe for the case under question, that's irrelevant, because
>>> we're only interested in access to inherited columns as those are the
>>> only ones that can be accessed in
On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote:
>
> Amit Langote writes:
> > On Sat, Jul 14, 2018 at 11:29 PM Tom Lane wrote:
> >> Peter Eisentraut writes:
> >>> ... For
> >>> partitioning, we can rely on all the columns being inherited, but not
> >>> for plain inheritance.
>
> >> Uh, what?
>
Amit Langote writes:
> On Sat, Jul 14, 2018 at 11:29 PM Tom Lane wrote:
>> Peter Eisentraut writes:
>>> ... For
>>> partitioning, we can rely on all the columns being inherited, but not
>>> for plain inheritance.
>> Uh, what?
> But maybe for the case under question, that's irrelevant, because
On Sat, Jul 14, 2018 at 11:29 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > ... For
> > partitioning, we can rely on all the columns being inherited, but not
> > for plain inheritance.
>
> Uh, what?
Maybe he meant that partitioning doesn't allow locally defined columns
in children, but
Peter Eisentraut writes:
> ... For
> partitioning, we can rely on all the columns being inherited, but not
> for plain inheritance.
Uh, what?
regards, tom lane
On 12.07.18 00:52, Tom Lane wrote:
>> Another question that could be raised is why we are refusing to use
>> stats for a child table when the caller has select on the parent.
>> It's completely trivial to extract data from a child table if you
>> have select on the parent, so it seems like we are
I wrote:
> I propose to run through the system operator classes, find any for which
> the comparison function isn't marked leakproof but the operators are,
> and fix them. This is clearly appropriate for HEAD and maybe it's not
> too late to force an initdb for v11 --- thoughts?
I did that for
On 2018-Jul-10, Tom Lane wrote:
> I propose to run through the system operator classes, find any for which
> the comparison function isn't marked leakproof but the operators are,
> and fix them. This is clearly appropriate for HEAD and maybe it's not
> too late to force an initdb for v11 ---
35 matches
Mail list logo
