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 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
