From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | david(at)calascibetta(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17258: Unexpected results in CHAR(1) data type |
Date: | 2021-10-29 18:57:51 |
Message-ID: | 19D58355-E7C3-47D7-9C87-51EC751AE2BB@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On Oct 29, 2021, at 11:14 AM, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>
> select length(substr(' '::varchar,1,1)), ascii(substr('
> '::varchar,1,1));
> produces==> 1 32 (as expected)
>
> select length(substr(' '::char,1,1)), ascii(substr(' '::char,1,1));
> produces==> 0 0 (not as expected)
There are four substr() functions defined in the standard distribution. They are:
substr(text, int4, int4)
substr(text, int4)
substr(bytea, int4, int4)
substr(bytea, int4)
There is none defined directly for char(n). Since "text" is the preferred type (not "bytea"), I expect a cast of your ' '::char to text before entry to the function. So the question is why casting ' '::char to text is different than ' '::text. The answer is that cast is implemented using rtrim1, which trims trailing space.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-10-29 19:04:20 | Re: BUG #17245: Index corruption involving deduplicated entries |
Previous Message | Alvaro Herrera | 2021-10-29 18:52:02 | Re: BUG #17245: Index corruption involving deduplicated entries |