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
