X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 267A6DA8CE for ; Fri, 21 Oct 2005 11:16:06 -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 69913-08 for ; Fri, 21 Oct 2005 14:16:01 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by svr1.postgresql.org (Postfix) with ESMTP id C5394DA8AF for ; Fri, 21 Oct 2005 11:16:03 -0300 (ADT) Received: by wproxy.gmail.com with SMTP id 71so260308wra for ; Fri, 21 Oct 2005 07:16:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DGx3mPa9YrjCvkhChKuJDTn5W/F9IiMdsDDXXLADWWOGfrGxlIWXnV/ksHQhDdDgJyXpJemZOusaG4wA6IoZI6JPOXSRMSPXPIBavqMTV5geJwBejFyM1/j+hhO4kPdaaB49Li18d3GtD8bA4XinV8bYvbWtF0E7fQ4Th7LKfZA= Received: by 10.54.141.17 with SMTP id o17mr1536688wrd; Fri, 21 Oct 2005 07:16:08 -0700 (PDT) Received: by 10.54.86.17 with HTTP; Fri, 21 Oct 2005 07:16:08 -0700 (PDT) Message-ID: <33c6269f0510210716x474dae2ah3861d32d8db01602@mail.gmail.com> Date: Fri, 21 Oct 2005 10:16:08 -0400 From: Alex Turner To: "Marc G. Fournier" Subject: Re: [pgsql-advocacy] Oracle buys Innobase Cc: Doug Quale , pgsql-general@postgresql.org In-Reply-To: <20051020214518.Q1006@ganymede.hub.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18106_2043455.1129904168543" References: <878xwokk4d.fsf@charter.net> <20051020214518.Q1006@ganymede.hub.org> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.152 required=5 tests=[AWL=0.041, HTML_40_50=0.086, HTML_MESSAGE=0.001, RCVD_BY_IP=0.024] X-Spam-Level: X-Archive-Number: 200510/1356 X-Sequence-Number: 85585 ------=_Part_18106_2043455.1129904168543 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline It appears that casting to a char() causes spaces to be stripped (ignored) from the string: mls=3D# select length('123 '::char(8)); length -------- 3 (1 row) mls=3D# select length('123 '::char(8)::varchar(8)); length -------- 3 (1 row) but: mls=3D# select length('123 '::varchar(8)); length -------- 6 (1 row) I'm not sure about anyone else, but I would personaly consider that a bug? Should the length function return the correct length of a fixed length string, or the length of significant characters? What does the SQL standard say on this one? I googled it a bit, but didn't come up with much. Alex Turner NetEconomist On 10/20/05, Marc G. Fournier wrote: > > On Thu, 20 Oct 2005, Doug Quale wrote: > > > "Guy Rouillier" writes: > > > >> Doug Quale wrote: > >>> > >>> # select 'a'::char(8) =3D 'a '::char(8); > >>> ?column? > >>> ---------- > >>> t > >>> (1 row) > >>> > >>> Trailing blanks aren't significant in fixed-length strings, so the > >>> question is whether Postgresql treats comparison of varchars right. > >> > >> This result is being misinterpreted. > >> > >> select length('a'::char(8)) =3D=3D> 1 > >> select length('a '::char(8)) =3D=3D> 1 > >> > >> So it isn't that the two different strings are comparing equal. The > >> process of casting them to char(8) is trimming the blanks, so by the > >> time they become fixed length strings, they are indeed equal. > > > > Huh??? What version of PG are you using? On 7.4.9, > > > > > > test=3D# select length('a'::char(8)); > > length > > -------- > > 8 > > (1 row) > > > > test=3D# select length('a '::char(8)); > > length > > -------- > > 8 > > (1 row) > > > > The truncation you describe would simply be wrong. > > ams=3D# select length('a '::char(8)); > length > -------- > 1 > (1 row) > > ams=3D# select version(); > version > ---------------------------------------------------------------------- > PostgreSQL 8.0.2 on i386-portbld-freebsd4.11, compiled by GCC 2.95.4 > (1 row) > > ams=3D# > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > ------=_Part_18106_2043455.1129904168543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
It appears that casting to a char() causes spaces to be stripped (ignored) = from the string:
mls=3D# select length('123   '::char(8));
 length
--------
      3
(1 row)


mls=3D# select length('123   '::char(8)::varchar(8));
 length
--------
      3
(1 row)


but:
mls=3D# select length('123   '::varchar(8));
 length
--------
      6
(1 row)

I'm not sure about anyone else, but I would personaly consider that a bug?  Should the length function return the correct length of a fixed length string, or the length of significant characters?  What does the SQL standard say on this one?  I googled it a bit, but didn't come up with much.

Alex Turner
NetEconomist


On 10/20/05, Marc G. Fournier <scrappy@postgresql.org> wrote:
On Thu, 20 Oct 2005, Doug Quale wrote:

> "Guy Rouillier"= ; <guyr@masergy.com> writes:<= br>>
>> Doug Quale wrote:
>>>
>>> # sel= ect 'a'::char(8) =3D 'a '::char(8);
>>>  ?column?
>>> ----------
>>= >  t
>>> (1 row)
>>>
>>> T= railing blanks aren't significant in fixed-length strings, so the
>&g= t;> question is whether Postgresql treats comparison of varchars right.
>>
>> This result is being misinterpreted.
>>>> select length('a'::char(8)) =3D=3D> 1
>> select leng= th('a '::char(8)) =3D=3D> 1
>>
>> So it isn't that the= two different strings are comparing equal.  The
>> process of casting them to char(8) is trimming the blanks, so = by the
>> time they become fixed length strings, they are indeed e= qual.
>
> Huh??? What version of PG are you using?  O= n 7.4.9 ,
>
>
> test=3D# select length('a'::char(8));
> len= gth
> --------
>      8
> (= 1 row)
>
> test=3D# select length('a '::char(8));
> lengt= h
> --------
>      8
> (1 row)
>
> The truncation you describe would simply b= e wrong.

ams=3D# select length('a '::char(8));
  length=
--------
       1
(1 row)

am= s=3D# select version();
        =             &nb= sp;           versio= n
----------------------------------------------------------------------<= br>  PostgreSQL 8.0.2 on i386-portbld-freebsd4.11, compiled by GC= C 2.95.4
(1 row)

ams=3D#


----
Marc G. Fournier = ;          Hub.Org Networking Services (http://www.hub.org= )
Email: scrappy@hub.org   &nb= sp;       Yahoo!: yscrappy           &= nbsp;  ICQ: 7615664

---------------------------(end of broadcast)---------------= ------------
TIP 6: explain analyze is your friend

------=_Part_18106_2043455.1129904168543--