Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group