On Thu, Dec 24, 2020 at 10:50:34AM +0900, Michael Paquier wrote: > FWIW, it still makes the most sense to me to keep the options that are > extracted from the grammar or things that apply to all the > sub-routines of REINDEX to be tracked in a single structure, so this > should include only the REINDEXOPT_* set for now, with the tablespace > OID as of this thread, and also the reindex filtering options. > REINDEX_REL_* is in my opinion of a different family because they only > apply to reindex_relation(), and partially to reindex_index(), so they > are very localized. In short, anything in need of only > reindex_relation() has no need to know about the whole ReindexOption > business.
I need more coffee here.. reindex_relation() knows about ReindexOptions. Still it would be weird to track REINDEX_REL_* at a global level as ExecReindex(), ReindexTable(), ReindexMultipleTables() and the like don't need to know about that. -- Michael
signature.asc
Description: PGP signature
