Subject: Re: Blank-padding
From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Chris Travers <chris@travelamericas.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	"Dean Gibson (DB Administrator)" <postgresql4@ultimeth.com>,
	pgsql-sql <pgsql-sql@postgresql.org>
In-Reply-To: <4359D081.7080105@travelamericas.com>
References: 
 <CC1CF380F4D70844B01D45982E671B239E8BEC@mtxexch01.add0.masergy.com>
	<878xwokk4d.fsf@charter.net> <20051020214518.Q1006@ganymede.hub.org>
	<33c6269f0510210716x474dae2ah3861d32d8db01602@mail.gmail.com>
	<23805.1129913241@sss.pgh.pa.us> <435979B0.60107@ultimeth.com>
	<27840.1129951428@sss.pgh.pa.us> <4359D081.7080105@travelamericas.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1130164369.15546.80.camel@state.g2switchworks.com>
Mime-Version: 1.0
Date: Mon, 24 Oct 2005 09:32:49 -0500

On Sat, 2005-10-22 at 00:39, Chris Travers wrote:
> 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.

If I rememberate correctificantly, this problem is or was caused by the
|| operator using the same internal logic for varchar / text AND char. 
Tom, is it reasonable / doable to have || have a different set of
internal functions for each of those types.