Re: Allow table AMs to define their own reloptions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Allow table AMs to define their own reloptions
Date
Msg-id a15db9d5-3ebb-4e6a-80e9-c900aad638a0@dunslane.net
Whole thread
In response to Re: Allow table AMs to define their own reloptions  (Ajit Awekar <ajitpostgres@gmail.com>)
Responses Re: Allow table AMs to define their own reloptions
List pgsql-hackers


[please don't top-post]


On 2026-09-30 We 4:35 AM, Ajit Awekar wrote:
I tested v8 and found below two issues.

1. SET before RESET.  Final state (heap, fillfactor=50) is valid. but resulting in an error ERROR:  unrecognized parameter "option_int". However Reset before set works as expected.



Yes, that's a bug.  v9 skips  the per-subcommand check when SET ACCESS METHOD is queued in the same statement. The deferred check still rejects unknown names and out-of-range values, and there are tests for both orders as well as those cases.



2.The current dummy_table_am always embeds StdRdOptions, so it cannot
  catch this. For this issue  make dummy_table_am's struct start with
  {int32 vl_len_; int pad1; int pad2; int option_int;}, keep only the
  option_int registration, dt_relopt_tab[1], and set
  has_std_options_prefix = false.


The bug is fixed in v9. I've added a second dummy AM to the test that doesn't embed StdRdoptions, so we could catch issues like this in future.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #19686: Rolling back SET TABLESPACE
Next
From: Alexandre Felipe
Date:
Subject: Re: BUG #19686: Rolling back SET TABLESPACE