Re: Blank-padding

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