Hi, Currently all the storage options for a table are very much specific to the heap but a different AM might need some user defined AM specific parameters to help tune the AM. So here is a patch which provides an AM level routine so that instead of getting parameters validated using “heap_reloptions” it will call the registered AM routine.
e.g: -- create a new access method and table using this access method CREATE ACCESS METHOD myam TYPE TABLE HANDLER <new_tableam_handler>; CREATE TABLE mytest (a int) USING myam ; --a new parameter is to set storage parameter for only myam as below ALTER TABLE mytest(squargle_size = '100MB'); The user-defined parameters will have meaning only for the "myam", otherwise error will be thrown. Our relcache already allows the AM-specific cache to be stored for each relation. Open Question: When a user changes AM, then what should be the behavior for not supported storage options? Should we drop the options and go with only system storage options? Or throw an error, in which case the user has to clean the added parameters. Thanks & Regards SadhuPrasad http://www.EnterpriseDB.com/
v1-0001-PATCH-v1-Per-table-storage-parameters-for-TableAM.patch
Description: Binary data
