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

From Takahiro Itagaki
Subject Re: BUG #5438: Bug/quirk in ascii() function
Date
Msg-id 20100426191149.9282.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to BUG #5438: Bug/quirk in ascii() function  ("Christoph Zwerschke" <cito@online.de>)
Responses Re: BUG #5438: Bug/quirk in ascii() function  (Christoph Zwerschke <cito@online.de>)
List pgsql-bugs
"Christoph Zwerschke" <cito@online.de> wrote:

>    ascii(cast(' ' as char(1))),
>    ascii(cast(' ' as char))
> both give 0.
>
> I think this quirk should be fixed or at least mentioned in the
> documentation of ascii().

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. You could have the same result with other databases
if you define a char version of ascii().

=# CREATE FUNCTION ascii(bpchar) RETURNS integer AS 'ascii' LANGUAGE internal;
=# SELECT ascii(cast(' ' as char(1)));
 ascii
-------
    32
(1 row)

Do you know how the SQL standard mention the behavior? IMHO, postgres'
behavior is more reasonable because length(' '::char(1)) is 0.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center

pgsql-bugs by date:

Previous
From: "Christoph Zwerschke"
Date:
Subject: BUG #5438: Bug/quirk in ascii() function
Next
From: Christoph Zwerschke
Date:
Subject: Re: BUG #5438: Bug/quirk in ascii() function