From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fillfactor gets set to zero for toast tables |
Date: | 2010-05-31 19:01:26 |
Message-ID: | 17443.1275332486@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:
> Excerpts from Takahiro Itagaki's message of mi may 26 03:32:56 -0400 2010:
>> The new "default_only" field can be initialized only from the internal codes
>> and is not exported to user definded reloptions. We could add an additional
>> argument to add_xxx_reloption() functions, but it breaks ABI.
> Do we really need default_only entries in user-defined reloptions?
> 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).
There probably isn't anyone using them, yet, which seems to me to be
a good argument to fix any obvious deficiencies in the API *now*
before there actually is anyone who'll be affected. In particular,
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-05-31 19:06:38 | Re: functional call named notation clashes with SQL feature |
Previous Message | Bruce Momjian | 2010-05-31 18:56:42 | Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct |