Re: fillfactor gets set to zero for toast tables

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

In response to

Responses

Browse pgsql-hackers by date

  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