Fujita-san, On Thu, Jul 18, 2019 at 8:10 PM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote: > > On Thu, Jul 18, 2019 at 11:18 AM Amit Langote <amitlangot...@gmail.com> wrote: > > On Tue, Jul 16, 2019 at 8:22 PM Etsuro Fujita <etsuro.fuj...@gmail.com> > > wrote: > > > On Tue, Jul 2, 2019 at 6:29 PM Amit Langote <amitlangot...@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
