Modifying TOAST thresholds

In another thread I wrote:
> ... One thing I was just thinking about is that it's silly to have
> the threshold constrained so strongly by a desire that tuples in toast
> tables not be toastable.  It would be trivial to tweak the heapam.c
> routines so that they simply don't invoke the toaster when relkind is
> 't', and then we could have independent choices of toast-tuple size and
> main-tuple size.  This would be particularly good because in the current
> scheme you can't modify toast-tuple size without an initdb, but if that
> were decoupled there'd be no reason not to allow changes in the
> main-tuple thresholds.

After thinking about this more I'm convinced that the above is a good
idea, eg in heap_insert change
   if (HeapTupleHasExternal(tup) || tup->t_len > TOAST_TUPLE_THRESHOLD)       heaptup =
toast_insert_or_update(relation,tup, NULL, use_wal);   else       heaptup = tup;
 

to
   if (relation->rd_rel->relkind == RELKIND_TOASTVALUE)   {       /* toast table entries should never be recursively
toasted*/       Assert(!HeapTupleHasExternal(tup));       heaptup = tup;   }   else if (HeapTupleHasExternal(tup) ||
tup->t_len> TOAST_TUPLE_THRESHOLD)       heaptup = toast_insert_or_update(relation, tup, NULL, use_wal);   else
heaptup= tup;
 

I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
compiled-in parameters that are recorded in pg_control and checked for
compatibility at startup (like BLCKSZ) --- this will prevent anyone from
shooting themselves in the foot while experimenting.

Any objections?
           regards, tom lane