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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: David(at)calascibetta(dot)com
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(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 22:08:12
Message-ID: CAKFQuwaiyVsPu0_z1sDQqVcFbKpLLzYuUnYca-fC+VdwN7OREg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Oct 29, 2021 at 2:59 PM David M. Calascibetta <
david(at)calascibetta(dot)com> wrote:

> They should behave the same, in that if I insert a blank into a char(1)
> column, it should store a blank value.
> If I insert a blank into a varchar(1) column, it should store a blank
> value. Fixed length characters would pad
> on the right, but it should not distort the value I entered in any other
> way. In this case, I enter a blank value and
> PG removes it. That is not appropriate behavior.
>
>
As implemented it has no way to distinguish between user-added trailing
whitespace and padding-added trailing whitespace. So instead it just says
"trailing whitespace is insignificant" and, further, insignificant
whitespace is discarded when converting to a data type that doesn't have
the concept of insignificant whitespace.

I don't necessarily agree with this either, but I'm in favor of the
position that char is obsolete and should not be used in new development,
nor should it be expected to be maintained.

David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Mark Dilger 2021-10-29 22:09:46 Re: BUG #17258: Unexpected results in CHAR(1) data type
Previous Message Peter Geoghegan 2021-10-29 22:06:52 Re: BUG #17245: Index corruption involving deduplicated entries