| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Reloptions for table access methods |
| Date: | 2020-09-01 06:18:39 |
| Message-ID: | 429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| reloptions.diff | text/x-patch | 594 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2020-09-01 06:34:34 | Re: Disk-based hash aggregate's cost model |
| Previous Message | Sait Talha Nisanci | 2020-09-01 06:14:52 | RE: [EXTERNAL] Re: WIP: WAL prefetch (another approach) |