Re: generic reloptions improvement

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>>> I'm intending to have a new routine which would reserve a value at
>>>> runtime.  This value would be later be passed by the AM to create new
>>>> options on the table.
>>> What do you mean by "at runtime"?  Surely the value would have to remain
>>> stable across database restarts, since it's going to relate to stuff
>>> that is in catalog entries.
>> No, there's no need for the value to be stable across restart; what's
>> stored in catalogs is the option name, which is linked to the kind
>> number only in the parser table.
> 
> So this is an updated patch.  This now allows a user-defined AM to
> create new reloptions and pass them down to the parser for parsing and
> checking.  I also attach a proof-of-concept patch that adds three new
> options to btree (which do nothing apart from logging a message at
> insert time).  This patch demonstrates the coding pattern that a
> user-defined AM should follow to add and use new storage options.
> 
> The main thing I find slightly hateful about this patch is that the code
> to translate from the returned relopt_value array and the fixed struct
> is rather verbose; and that the AM needs to duplicate the code in
> default_reloptions.  I don't find it ugly enough to warrant objecting to
> the patch as a whole however.
> 
> The neat thing about this code is that the parsing and searching is done
> only once, when the relcache entry is loaded.  Later accesses to the
> option values themselves is just a struct access, and thus plenty quick.

This patch does not support reloptions in string expression, like:
 CREATE TABLE t1 (     a int,     b text ) WITH (default_row_acl='{yamada=r/kaigai}');

Do you have any plan to support reloptions in string?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>