Fujita-san,
On Thu, Jul 18, 2019 at 8:10 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>
> On Thu, Jul 18, 2019 at 11:18 AM Amit Langote <amitlangote09@gmail.com> wrote:
> > On Tue, Jul 16, 2019 at 8:22 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> > > On Tue, Jul 2, 2019 at 6:29 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > > > 0001 - fix partitionwise join to work correctly with n-way joins of
> > > > which some are full joins (+ cosmetic improvements around the code
> > > > that was touched)
> > >
> > > Here are my comments about the cosmetic improvements: they seem pretty
> > > large to me, so I'd make a separate patch for that.
> >
> > OK, my bad that I added so many cosmetic changes into a patch that is
> > meant to fix the main issue. Just to clarify, I'm proposing these
> > cosmetic improvements to better clarify the terminological separation
> > between nullable and non-nullable partition keys, which I found a bit
> > hard to understand as is.
>
> OK, thanks for the explanation!
>
> > I've broken the patch into two: 0001 contains only cosmetic changes
> > and 0002 the fix for handling full joins properly. Would you rather
> > that be reversed?
>
> I like this order.
>
> > > In addition, I'd
> > > move have_partkey_equi_join() and match_expr_to_partition_keys() to
> > > relnode.c, because these functions are only used in that file.
> >
> > I hadn't noticed that. Makes sense to move them to relnode.c, which
> > is implemented in 0001.
>
> Thanks for including that! Will review.
To avoid losing track of this, I've added this to November CF.
https://commitfest.postgresql.org/25/2278/
I know there is one more patch beside the partitionwise join fix, but
I've set the title to suggest that this is related mainly to
partitionwise joins.
Thanks,
Amit