From: | gkokolatos(at)pm(dot)me |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reloptions for table access methods |
Date: | 2020-09-01 10:36:51 |
Message-ID: | oKDqKIuw5QQHapDmb1wmCkQaLvp-KpGGg0HKFX2IHljw2puQL9Zj-0qTo0FDhS_lEAMab_whH5V_FzpD0wuJrFiedCV0di0rJg9ks7HKYYA=@pm.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 1 September 2020 09:18, Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Li Japin | 2020-09-01 10:37:40 | Docs: inaccurate description about config settings |
Previous Message | Alexey Kondratov | 2020-09-01 10:36:38 | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |