Re: Reloptions for table access methods

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 1 September 2020 09:18, Jeff Davis <pgsql@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
essentialpart 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
beenquite a pain to do cleanly. Given the nature of Greenplum's table access methods, we were forced to take it a
coupleof steps further. We did use an approach which I am certain that you have considered and discarded as
over-engineeringfor postgres. 

In short, I am really excited to see a patch for this topic!

>
> Regards,
> Jeff Davis