Re: [HACKERS] Progress on char(n) default-value problem

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Good analysis.  I am sure this is a byproduct of my change in 6.? that
> allowed optimzation of char() fields by assuming they are all a fixed
> length.  Of course, 99% of the time they were, so it never bit us,
> except with default.

There's nothing wrong with your optimization --- a char(n) field should
be n characters 100% of the time.  It's the default-insertion code
that's busted.

> At least an Assert().  However, the tuple access routines do an
> auto-compute of column offsets on the first table access, so it never
> really looks at the tuples in between.  However, an Assert should check
> that when you access a char() field, that it is really the proper
> length.  Good idea.

No, I think the Assert ought to be on the output side.  You might never
try to access the char(n) field itself, only the following fields;
if the attcacheoff fields are already set up when you come to the
bogus tuple, an Assert in the reading side wouldn't catch it.
        regards, tom lane