From: | Christoph Zwerschke <cito(at)online(dot)de> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5438: Bug/quirk in ascii() function |
Date: | 2010-04-26 12:00:29 |
Message-ID: | 4BD5805D.5070904@online.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Donald Fraser | 2010-04-26 13:51:35 | Bug with Tsearch and tsvector |
Previous Message | Takahiro Itagaki | 2010-04-26 10:11:49 | Re: BUG #5438: Bug/quirk in ascii() function |