Re: Efficient slicing/substring of TOAST values (reprise)

John Gray <jgray@azuli.co.uk> writes:
> 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.

This is doable, but it's uglier because the functions need to know a lot
more about toasting; is it really worth it?

> 2. commands/command.c Some of the recursion to inherited tables passes
> the inhOpt from the parent rather than setting false.

That would be a bug, but I can't see any such error in current CVS.
Where are you looking?

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

Should it?  They'd be ignored anyway by most internal operations.
I suppose at the very least it should check usecatupd...

> 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)

There is some documentation in xfunc.sgml, but I have no objection to
transposing more of the README into the SGML docs.  Just haven't got
round to it.

> 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.

Not sure that that's safe; need to think more.

            regards, tom lane