X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B2139DAAA8 for ; Sat, 22 Oct 2005 12:16:52 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 66700-08 for ; Sat, 22 Oct 2005 15:16:51 +0000 (GMT) Received: from mail.mailpen.net (mail.mailpen.net [66.235.70.248]) by svr1.postgresql.org (Postfix) with ESMTP id 0757FDA7BF for ; Sat, 22 Oct 2005 12:16:50 -0300 (ADT) Received: from athlon1.internal.mailpen.net (pool-71-113-21-206.sttlwa.dsl-w.verizon.net [71.113.21.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mailpen.net (Postfix) with ESMTP id BC50B11 for ; Sat, 22 Oct 2005 08:16:49 -0700 (PDT) Received: from [192.168.128.199] (TpA22p1.internal.mailpen.net [192.168.128.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by athlon1.internal.mailpen.net (Postfix) with ESMTP id 979B16DC060 for ; Sat, 22 Oct 2005 08:16:48 -0700 (PDT) Message-ID: <435A57E0.3050006@ultimeth.com> Date: Sat, 22 Oct 2005 08:16:48 -0700 From: "Dean Gibson (DB Administrator)" Organization: UltiMeth Systems User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: pgsql-sql Subject: Re: Blank-padding References: <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> In-Reply-To: <27840.1129951428@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 required=5 tests=[AWL=-0.000, FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200510/254 X-Sequence-Number: 23107 On 2005-10-21 20:23, Tom Lane wrote: > "Dean Gibson (DB Administrator)" 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 (oops, trailing) 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. 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. > > regards, tom lane > It's one thing, as with floating point values, where the internal representation is identical (1.0 stored identically to 1.00), and another thing where the internal representation is different (a la strings storing 'abc ' differently from 'abc'. While programming languages may differ as to how they compare those two strings, every one that I'm familiar with does not strip trailing spaces when concatenating. It's not an issue with me, but the 8.0 concatenation does violate the "Principle of Least Astonishment". As does treating 'abc ' and 'abc' different during comparisons (which 8.0 fixed). So my tentative argument would be, strip trailing spaces on CHAR(n) comparisons but not on concatenation or assignment, because you lost information. You can always strip if you need to (as you do in other languages). As I said, this issue doesn't presently affect my databases, it's just an observation. -- Dean