On Sat, 2005-10-22 at 00:39, Chris Travers wrote:
> 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.
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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
