Packed short varlenas, what next?

I'm really curious to know how people feel about the varlena patch. In
particular I know these issues may elicit comment:

1) Do we really need a special case for little-endian machines? I think it  would be trivial to add but having two code
pathsmay be annoying to  maintain. The flip side is it would make it easier to read varlena headers  in gdb which I
foundkind of annoying with them in network byte order.
 

2) How do people feel about the way I inlined most of the VARATT_IS_SHORT  cases in heaptuple.c. I tried at first to
hidethat all in the att_align  and att_addlength macros but a) it would never be possible to hide most of  it and b) it
wouldrequire a few more redundant tests.
 

3) How do people feel about not allowing an escape hatch for new types and  explicitly exempting int2vector and
oidvector.The alternatives are either  a) adding a new column to pg_type and pg_attribute and setting that on  catalog
attributesthat are accessed through GETSTRUCT (as the first  varlena in the table) and also setting it on oidvector and
int2vector because they don't call pg_detoast_datum(). Or b) fixing int2vector and  oidvector to pass through
pg_detoast_datumand fix all the accesses to the  first int2vector/oidvector in every catalog table to use fastgetattr
instead.or c) keep things as they are now.
 

4) Should I start hitting the more heavily trod codepaths in text.c and  numeric.c to avoid detoasting short varlenas?
Themacro api is not quite  complete enough for this yet so it may make sense to tackle at least one  code site before
mergingit to be sure we have a workable api for data  types that want to avoid unnecessary detoasting.
 

The latest patch is at 
http://community.enterprisedb.com/varlena/patch-varvarlena-12.patch.gz

I've been doing some benchmarking, I see a 9.7% space saving on the
Benchmark-SQL 5.2 schema which translates into about a 8% performance gain.
The DBT2 benchmarks show a smaller 5.3% space saving because we had already
done a lot more optimizing of the schema. 

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com