‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 1 September 2020 09:18, Jeff Davis <pg...@j-davis.com> wrote:
> 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.
I have yet to look at the diff. I simply wanted to give you my wholehearted +1
to the idea. It is a necessary and an essential part of developing access
methods.
I have worked extensively in the merge of PG12 into Greenplum, with a focus to
the tableam api. Handling reloptions has been quite a pain to do cleanly. Given
the nature of Greenplum's table access methods, we were forced to take it a
couple of steps further. We did use an approach which I am certain that you
have considered and discarded as over-engineering for postgres.
In short, I am really excited to see a patch for this topic!
>
> Regards,
> Jeff Davis
