FW: BUG #17258: Unexpected results in CHAR(1) data type

-----Original Message-----
From: David M. Calascibetta <david(at)calascibetta(dot)com>
Sent: Friday, October 29, 2021 2:04 PM
To: 'Mark Dilger' <mark(dot)dilger(at)enterprisedb(dot)com>
Subject: RE: BUG #17258: Unexpected results in CHAR(1) data type

Ok, but my example was just a simplified version of what is going on.
The actual problem stems from a CHAR(1) column data type that is behaving the same way.
I was just trying to create a super-simple example of the problem.
It still seems to me that a CHAR(1) should never be zero length, regardless of how it's implemented.

-----Original Message-----
From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Sent: Friday, October 29, 2021 1:58 PM
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

> 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