Efficient slicing/substring of TOAST values (reprise)

I attach the new version of my patch for providing
PG_GETARG_xxx_P_SLICE() macros and associated support routines.

Contents of this patch:

1. Routines in src/backend/access/tuptoaster.c for fetching only
necessary chunks of a toasted value.

2. Amended text_substr and bytea_substr to use new methods.

3. Added new command: ALTER TABLE tabname ALTER COLUMN colname SET
STORAGE {PLAIN | EXTERNAL | EXTENDED | MAIN} to parser and documented in
alter-table.sgml. (NB I used ColId as the item type for the storage
mode, I hope this makes sense!). All this does is sets attstorage for
the specified column.

4. Rearrangements of ALTER TABLE ALTER COLUMN to tidy it up.
AlterTableAlterColumnStatistics is now AlterTableAlterColumnFlags and
uses the subtype code to distinguish. Setup code (permissions checks
etc.) moved to new routine, macro for the loop that generates all
inheritors. I have merged Tom Lane's patches (though he may want to
check that it's been done correctly).

5. Documented new macros (and also the PG_GETARG_xxx_P_COPY macros) is
xfunc.sgml.

Things I've noticed in passing:

1. utils/adt/varlena.c There could be some performance gains for the
length functions if the PG_GETARG API allowed for finding the length of
a value without detoasting it.

2. commands/command.c Some of the recursion to inherited tables passes
the inhOpt from the parent rather than setting false. If
find_all_inheritors does what it says (i.e. it finds all children,
grandchildren etc.), we could save some wasted effort by using false
instead.

3. alter table add constraint doesn't (on the face of it) prevent adding
constraints to system tables if you're the superuser.

4. New function-call interface is mainly documented in fmgr/README which
is in the future tense. Should this go into a reference manual section
instead? (those bits that it's good for programmer-users to know)

I haven't done anything on the update issue. We need to think about:

1) Syntax (how to specify a partial update of a column).

and

2) TOAST valueids. If MVCC works just as well on TOAST tables, then the
update process is much simplified as an amended value doesn't need a new
valueid.

I'm going to be away now until the 23rd, but please let me know if
there's anything I can do on my return. I'm happy to take comments and
rework this as necessary.

Regards

John

--
John Gray
Azuli IT http://www.azuli.co.uk +44 121 693 3397
jgray(at)azuli(dot)co(dot)uk