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.
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 |