Neil Conway <neilc@samurai.com> writes:
> On Wed, 2006-06-14 at 16:56 -0400, Bruce Momjian wrote:
>> The code churn to do this is going to be quite significant
> Why do you say that? Although the original patch posted to implement
> this was incomplete, it certainly wasn't very large.
IIRC, the original idea would have forced code changes on every existing
varlena datatype ... not just those in our source tree, but outside
users' custom types as well. You'd need a really *serious* gain to
justify that.
The second idea was to leave existing varlena types as-is and invent
a set of "small text" etc datatypes alongside them. This is simply
ugly (shades of Oracle's varchar2), and again there wasn't really an
adequate case made why we should burden users with extra complexity.
The variant I could have supported was making a "2-byte-header" class of
types and using it just for the few types where it would be sufficient
(numeric and inet, basically). That would be transparent to everyone.
Whether it's worth the trouble is not clear given that it'd only help a
few datatypes, but would add cycles in critical inner loops in places
like heap_deformtuple.
regards, tom lane
