Re: generic reloptions improvement

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera <alvherre(at)commandprompt(dot)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(at)kaigai(dot)gr(dot)jp>