On Wed, Sep 02, 2020 at 10:00:12AM +0900, Michael Paquier wrote: > On Tue, Sep 01, 2020 at 11:48:30AM -0400, Alvaro Herrera wrote: > > On 2020-Sep-01, Justin Pryzby wrote: > >> The question isn't whether to use a parenthesized option list. I realized > >> that > >> long ago (even though Alexey didn't initially like it). Check 0002, which > >> gets > >> rid of "bool concurrent" in favour of stmt->options&REINDEXOPT_CONCURRENT. > > > > Ah! I see, sorry for the noise. Well, respectfully, having a separate > > boolean to store one option when you already have a bitmask for options > > is silly. > > Yeah, I am all for removing "concurrent" from ReindexStmt, but I don't > think that the proposed 0002 is that, because it is based on the > assumption that we'd want more than just boolean-based options in > those statements, and this case is not justified yet except if it > becomes possible to enforce tablespaces. At this stage, I think that > it is more sensible to just update gram.y and add a > REINDEXOPT_CONCURRENTLY. I also think that it would also make sense > to pass down "options" within ReindexIndexCallbackState() (for example > imagine a SKIP_LOCKED for REINDEX).
Uh, this whole thread is about implementing REINDEX (TABLESPACE foo), and the preliminary patch 0001 is to keep separate the tablespace parts of that content. 0002 is a minor tangent which I assume would be squished into 0001 which cleans up historic cruft, using new params in favour of historic options. I think my change is probably incomplete, and ReindexStmt node should not have an int options. parse_reindex_params() would parse it into local int *options and char **tablespacename params. -- Justin
