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
