Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> 1|new |f | 1
>>
>> UPDATE test SET state = 'diff' WHERE plt = 1;
>>
>> 1|diff |t |26144
>>
>> ???
> This is scary, but not unexpected. I have a bug report in my mailbox
> that describes a similar problem with default. I am sure it is the
> same cause. Somewhere, default is broken, and it is on the Open Items
> list.
But the value looks correct at the first SELECT, so how could it be the
fault of the DEFAULT clause? Seems you are right though, because I can
reproduce the error given the stated table definition --- but not when
there's no defaults.
Interesting data point: my value for the trashed ID field comes out as
543555584 = 0x20660000, versus Tatsuo's 26144 = 0x00006620. My HP box
is big-endian hardware, and I'm guessing that Tatsuo is using something
little-endian. The data looks like it is the 'f' and space that would
be at the end of the "state" field. How did this get over into the "id"
field, especially without corrupting "used" in between?
Even more interesting: if I declare the state field asstate CHAR(5) NOT NULL DEFAULT 'new ',
all else the same, there's no error.
> I believe it is an improper default length field or rounding of length.
I think somehow, somewhere, the size of the default value is getting
used instead of the size of the field itself. Weird. Is it specific
to char(n), perhaps? That might help explain how the bug got past
the regression tests.
regards, tom lane