Skip site navigation (1) Skip section navigation (2)

Re: BUG #5438: Bug/quirk in ascii() function

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Christoph Zwerschke" <cito(at)online(dot)de>,<pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5438: Bug/quirk in ascii() function
Date: 2010-04-26 14:24:39
Message-ID: 4BD55BD70200002500030DD2@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
Christoph Zwerschke <cito(at)online(dot)de> wrote:
> Am 26.04.2010 12:11, schrieb Takahiro Itagaki:
 
>> Do you know how the SQL standard mention the behavior? IMHO,
>> postgres' behavior is more reasonable because
>> length(' '::char(1)) is 0.
> 
> Just found http://troels.arvin.dk/db/rdbms/ which claims that this
> is against the standard:
> 
>    "PostgreSQL: Stores CHARs in space padded form, but violates
>     the standard by (conceptually) truncating trailing white-space
>     before performing most functions, operators, and comparisons
>     (like the CHARACTER_LENGTH-function and the concatenation(||)
>     operator)."
> 
> Not sure if this is correct and how well-defined the SQL standard
> actually is in this regard. It seems Oracle does not remove
> trailing spaces when converting from char to varchar.
 
That is consistent with how I remember the standard (although I
don't have time right now to fight my way through it to confirm). 
My recollection is that char(n) should be treated exactly like a
varchar padded with spaces to n characters *except* for character
string comparisons, where trailing spaces are supposed to be
ignored.
 
-Kevin

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-04-26 14:55:16
Subject: Re: Bug with Tsearch and tsvector
Previous:From: Tom LaneDate: 2010-04-26 14:15:56
Subject: Re: BUG #5439: Table crash after CLUSTER command

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group