From: Mark Dilger <mark.dilger@enterprisedb.com>
To: david@calascibetta.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17258: Unexpected results in CHAR(1) data type
Date: Fri, 29 Oct 2021 11:57:51 -0700
Message-ID: <19D58355-E7C3-47D7-9C87-51EC751AE2BB@enterprisedb.com> (raw)
In-Reply-To: <17258-a7c164c5fb955221@postgresql.org>
References: <17258-a7c164c5fb955221@postgresql.org>
> On Oct 29, 2021, at 11:14 AM, PG Bug reporting form <noreply@postgresql.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: mark.dilger@enterprisedb.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17258: Unexpected results in CHAR(1) data type
In-Reply-To: <19D58355-E7C3-47D7-9C87-51EC751AE2BB@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox