| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | 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: | 2008-12-24 16:16:33 |
| Message-ID: | 11720.1230135393@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Peter Eisentraut wrote:
>> I'm not sure how important this is, but if you are enumerating the access
>> methods (RELOPT_KIND_BTREE, etc.), how will this work with user-defined
>> access methods?
> It is important.
> 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.
I'd feel more comfortable with a scheme that used the AM's pg_am OID.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-12-24 17:31:05 | Re: Window-functions patch handling of aggregates |
| Previous Message | Jaime Casanova | 2008-12-24 16:12:33 | Re: [idea] a copied relkind in pg_attribute |