On 2005-10-21 20:23, Tom Lane wrote:
> "Dean Gibson (DB Administrator)" <postgresql4@ultimeth.com> writes:
>
>> I remember that discussion, and I was for the change. However, upon
>> doing some testing after reading the above, I wonder if the
>> blank-stripping isn't too aggressive. I have a CHAR(6) field (say,
>> named Z) that has "abc " in it. Suppose I want to append "x" to Z,
>> with any leading (oops, trailing) spaces in Z PRESERVED.
>>
>
> (You meant trailing spaces, I assume.) Why exactly would you want to do that? You decided by your choice of
datatypethat the trailing spaces weren't significant. This gripe seems to me exactly comparable to complaining if a
numericdatatype doesn't remember how many trailing zeroes you typed after the decimal point. Those zeroes aren't
semanticallysignificant, so you have no case.
>
> regards, tom lane
>
It's one thing, as with floating point values, where the internal
representation is identical (1.0 stored identically to 1.00), and
another thing where the internal representation is different (a la
strings storing 'abc ' differently from 'abc'. While programming
languages may differ as to how they compare those two strings, every one
that I'm familiar with does not strip trailing spaces when concatenating.
It's not an issue with me, but the 8.0 concatenation does violate the
"Principle of Least Astonishment". As does treating 'abc ' and 'abc'
different during comparisons (which 8.0 fixed).
So my tentative argument would be, strip trailing spaces on CHAR(n)
comparisons but not on concatenation or assignment, because you lost
information. You can always strip if you need to (as you do in other
languages).
As I said, this issue doesn't presently affect my databases, it's just
an observation.
-- Dean