A custom table access method might want to add a new reloption to
control something specific to that table access method. Unfortunately,
if you add a new option of type RELOPT_KIND_HEAP, it will immediately
fail because of the validation that happens in fillRelOptions().
Right now, heap reloptions (e.g. FILLFACTOR) are validated in two
places: parseRelOptions() and fillRelOptions().
parseRelOptions() validates against boolRelOpts[], intRelOpts[], etc.
This validation is extensible by add_bool_reloption(), etc.
fillRelOptions() validates when filling in a struct to make sure there
aren't "leftover" options. It does this using a hard-coded parsing
table that is not extensible.
Index access methods get total control over validation of reloptions,
but that doesn't fit well with heaps, because all heaps need the
vacuum-related options.
I considered some other approaches, but they all seemed like over-
engineering, so the attached patch just passes validate=false to
fillRelOptions() for heaps. That allows custom table access methods to
just define new options of kind RELOPT_KIND_HEAP.
Regards,
Jeff Davis
diff --git a/src/backend/access/common/reloptions.c b/src/backend/access/common/reloptions.c
index 8ccc228a8cc..1eb3dc235b1 100644
--- a/src/backend/access/common/reloptions.c
+++ b/src/backend/access/common/reloptions.c
@@ -1908,7 +1908,7 @@ build_reloptions(Datum reloptions, bool validate,
/* allocate and fill the structure */
rdopts = allocateReloptStruct(relopt_struct_size, options, numoptions);
fillRelOptions(rdopts, relopt_struct_size, options, numoptions,
- validate, relopt_elems, num_relopt_elems);
+ false, relopt_elems, num_relopt_elems);
pfree(options);
