From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fillfactor gets set to zero for toast tables |
Date: | 2010-06-01 00:50:22 |
Message-ID: | 20100601095022.95C4.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Do we really need default_only entries in user-defined reloptions?
I think we don't, but I also think we don't need it at all even in the
core because it just set a few variables to the default values with
complex code flow. Could you explain why default_only entries idea is
better than adjusting those fields in the toast-specific codes?
It's my understanding that reloption-framework is just a tool to fill
reloption parameters, and it's not responsible for unused fields.
> > We have yet to see any indication that anybody is using user-defined
> > reloptions at all ... It'd be good to have an use case at least (if
> > only to ensure that the API we're providing is sufficient).
I use it my textsearch_senna extension :-).
But I don't need default_only entries at this time.
> I suggest that 9.0 would be a good time to add an "int flags" parameter
> to the add_xxx_reloption functions. The first flag could be
> default_only and we'd have room to add more later without another API
> break.
I agree the idea when we reach a conclusion to introduce default_only.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-06-01 00:50:35 | Re: is_absolute_path incorrect on Windows |
Previous Message | Bruce Momjian | 2010-06-01 00:33:49 | Re: Show schema name on REINDEX DATABASE |