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

I understand your position. I've been there myself.
We will convert the CHAR(1) columns to VARCHAR and keep going.
I just thought it was strange and you should know about it.
Not a problem.
Thanks for your attention.

David

-----Original Message-----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: Friday, October 29, 2021 5:23 PM
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: <David(at)calascibetta(dot)com> <David(at)Calascibetta(dot)com>;
pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17258: Unexpected results in CHAR(1) data type

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> I haven't studied the behavior of char(n) on other RDBMS products. I'd be
curious if the SQL spec says anything that we're violating in this regard.

It's not a great approximation to the spec. Postgres views trailing spaces
in a char(n) value as always being semantically insignificant, where I think
the spec treats them as insignificant only for purposes of comparisons.
Even more to the point, the spec considers that PAD SPACE is an attribute of
*collations* not data types. Back in the day we didn't have collations, so
the only way to even approximate that behavior was to make it a data type
property. Now that we do have collations, it'd be conceivable to
reimplement all this in something closer to the way the spec describes it.
But it'd be a lot of work, and I'm not sure we'd accept such a patch even if
somebody wrote it.
It'd almost inevitably break applications that are relying on the existing
behavior.

> I tend to think of char(n) as a misfeature and avoid using it.

Yeah, that. I haven't seen any reason to use char(n) rather than
varchar(n) since punched cards stopped being a thing. So it's hard to
summon the motivation to do a lot of work on that data type.

Perhaps somebody else will feel more motivated, but nobody's stepped
forward, and I wouldn't counsel holding your breath for it.

regards, tom lane