Re: move PartitionBoundInfo creation code
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Michael Paquier <michael@paquier.xyz>,
Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-08T03:59:27Z
Lists: pgsql-hackers
On 2018/11/08 11:48, Michael Paquier wrote: >>> Thinking crazy, we could also create a subfolder partitioning/bounds/ >>> which includes three files with this refactoring:x >>> - range.c >>> - values.c >>> - hash.c >>> Then we keep partbounds.c which is the entry point used by partcache.c, >>> and partbounds.c relies on the stuff in each other sub-file when >>> building a strategy. This move could be interesting in the long term as >>> there are comparison routines and structures for each strategy if more >>> strategies are added. >> >> I'm not sure this is worthwhile. You'll create a bunch of independent >> translation units in exchange for ...? > > That's the part about going crazy and wild on this refactoring. Not all > crazy ideas are worth doing, still I like mentioning all possibilities > so as we miss nothing in the review process. It might be okay to split the big switch in partition_bounds_create() into different functions for different partitioning methods for clarity as you say, but let's avoid creating new files for range, list, and hash. I will post an updated patch with that break down. Thanks, Amit
Commits
-
Refactor code creating PartitionBoundInfo
- b52b7dc250bb 12.0 landed