Re: BUG #5438: Bug/quirk in ascii() function - Mailing list pgsql-bugs

From Christoph Zwerschke
Subject Re: BUG #5438: Bug/quirk in ascii() function
Date
Msg-id 4BD5805D.5070904@online.de
Whole thread Raw
In response to Re: BUG #5438: Bug/quirk in ascii() function  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: BUG #5438: Bug/quirk in ascii() function  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-bugs
Am 26.04.2010 12:11, schrieb Takahiro Itagaki:
> The problem is not in ascii(), but in casting from char to text.
> We have only one version of ascii() in default; ascii(text).
> So, if you use ascii( ' '::char(1) ), it is actually handled as
> ascii( ' '::char(1)::text ). Traling spaces were removed during
> the cast to text.

Ok, that makes sense.

> 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.

-- Christoph

pgsql-bugs by date:

Previous
From: Takahiro Itagaki
Date:
Subject: Re: BUG #5438: Bug/quirk in ascii() function
Next
From: manohar cr
Date:
Subject: Re: pgadmin supports on SLES10.3