On Wed, May 09, 2018 at 02:01:26PM +0900, Amit Langote wrote: > On 2018/05/09 11:31, David Rowley wrote: >> On 9 May 2018 at 14:29, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >>> On 2018/05/09 11:20, Michael Paquier wrote: >>>> While looking at this code, is there any reason to not make >>>> gen_partprune_steps static? This is only used in partprune.c for now, >>>> so the intention is to make it available for future patches? >>> >>> Yeah, making it static might be a good idea. I had made it externally >>> visible, because I was under the impression that the runtime pruning >>> related code would want to call it from elsewhere within the planner. >>> But, instead it introduced a make_partition_pruneinfo() which in turn >>> calls get_partprune_steps. >> >> Yeah. Likely left over from when run-time pruning was generating the >> steps during execution rather than during planning. > > Here is a patch that does that.
Thanks, Amit. Alvaro, could it be possible to consider as well the patch I posted here? https://www.postgresql.org/message-id/20180424012042.gd1...@paquier.xyz This removes a useless default clause in partprune.c and it got forgotten in the crowd. Just attaching it again here, and it can just be applied on top of the rest. -- Michael
diff --git a/src/backend/partitioning/partprune.c b/src/backend/partitioning/partprune.c index f8844ef2eb..cbbb4c1827 100644 --- a/src/backend/partitioning/partprune.c +++ b/src/backend/partitioning/partprune.c @@ -2950,10 +2950,6 @@ perform_pruning_combine_step(PartitionPruneContext *context, } } break; - - default: - elog(ERROR, "invalid pruning combine op: %d", - (int) cstep->combineOp); } return result;
signature.asc
Description: PGP signature
