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

> But the tuple readout routines will assume without looking that char(5)
> occupies 9 bytes altogether, so they pick up the bool field 2 bytes over
> from where it actually was put and pick up the int4 field 4 bytes over
> from where it should be (due to alignment); result is garbage.  If there
> were another varlena field after the char(n) field, they'd pick up a
> wrong field length and probably crash.
> 
> 
> So, the question still remains "where and why"?  My guess at this point
> is that this is a bad side-effect of the fact that text and char(n) are
> considered binary-equivalent.  Probably, whatever bit of code ought to
> be coercing the default value into the correct type for the column is
> deciding that it doesn't have to do anything because they're already
> equivalent types.  I'm not sure where to look for that code (help
> anyone?).  But I am sure that it needs to be coercing the value to the
> specified number of characters for char(n).

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.  Not sure if default was added before or after my
optimization.

> It also strikes me that there should be a check in the low-level
> tuple construction routines that what they are handed for a char(n)
> field is the right length.  If tuple readout is going to assume that
> char(n) is always n bytes of data, good software engineering dictates
> that the tuple-writing code ought to enforce that assumption.  At
> the very least there should be an Assert() for it.

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.

BTW, I couldn't find the default stuffing code myself either.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026