Reloptions for table access methods - Mailing list pgsql-hackers

From Jeff Davis
Subject Reloptions for table access methods
Date
Msg-id 429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel@j-davis.com
Whole thread Raw
Responses Re: Reloptions for table access methods  (gkokolatos@pm.me)
Re: Reloptions for table access methods  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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

pgsql-hackers by date:

Previous
From: Sait Talha Nisanci
Date:
Subject: RE: [EXTERNAL] Re: WIP: WAL prefetch (another approach)
Next
From: Jeff Davis
Date:
Subject: Re: Disk-based hash aggregate's cost model