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 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.
I once built a telecom billing app where this might be important (fixed
length fields). Lets say you have fixed length fields defined as
char(n) datatypes. You may want to build a query to generate billing
records like:
select field1 || field2 || field3 || field4 || field5 ... AS bill_record
FROM lec_billing_entries;
It seels to me that I would expect trailing spaces to be preserved in
these cases. Having an implicit rtrim function is asking for problems.
Personally I would rather have to call rtrim explicitly than have the
backend treat the concatenation differently than if I do it on the client.
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.\
My only gripe here is that the implicit rtrimming is going to cause
problems in cases where you are trying to do things with fixed-length
fields, which is really where one is likely to use bpchar anyway. It is
not a showstopper, but I can see why some people don't like it. But
can't please everyone :-)
Best Wishes,
Chris Travers
Metatron Technology Consulting
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
