On 2005-10-21 20:23, Tom Lane wrote:
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> 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 datatype that the trailing spaces weren't
significant. This gripe seems to me exactly comparable to complaining if a
numeric datatype doesn't remember how many trailing zeroes you typed after the
decimal point. Those zeroes aren't semantically significant, 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
