Re: generic reloptions improvement

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Subject: Re: generic reloptions improvement
Date: 2009-01-03 12:42:08
Message-ID: 495F5D20.8050001@kaigai.gr.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-01-03 13:46:51 Re: generic reloptions improvement
Previous Message Dave Page 2009-01-03 10:59:38 Re: reloptions and toast tables