On Wed, Dec 23, 2020 at 07:22:05PM -0300, Alvaro Herrera wrote:
> Also: it seems a bit weird to me to put the flags inside the options
> struct. I would keep them separate -- so initially the options struct
> would only have the tablespace OID, on API cleanliness grounds:
I don't see why they'd be separate or why it's cleaner ?
If the user says REINDEX (CONCURRENTLY, VERBOSE, TABLESPACE ts) , why would we
pass around the boolean flags separately from the other options ?
> struct ReindexOptions
> {
> tablepaceOid oid;
> };
> extern bool
> reindex_relation(Oid relid, bits32 flags, ReindexOptions *options);
> But also, are we really envisioning that these routines would have all
> that many additional options? Maybe it is sufficient to do just
>
> extern bool
> reindex_relation(Oid relid, bits32 flags, tablespaceOid Oid);
That's what we did initially, and Michael suggested to put it into a struct.
Which makes the tablespace patches cleaner for each of REINDEX, CLUSTER,
VACUUM, since it doesn't require modifying the signature of 5-10 functions.
And future patches get to reap the benefit.
These are intended to be like VacuumParams. Consider that ClusterOptions is
proposed to get not just a tablespaceOid but also an idxtablespaceOid.
This was getting ugly:
extern void reindex_index(Oid indexId, bool skip_constraint_checks,
char relpersistence, int options, Oid tablespaceOid);
--
Justin
