hubert depesz lubaczewski <depesz@depesz.com> writes:
> On Wed, Jul 31, 2024 at 04:47:23AM +0000, PG Bug reporting form wrote:
>> CREATE TABLE t0(c0 INT NOT NULL, c1 CHAR(1) UNIQUE);
> I bet the thing is simply one more edge case that proves that one
> shouldn't be using char(n) datatype:
> https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_char.28n.29
Yeah, exactly. Some surprising choices were made way-back-when about
which char(N) operations ought to ignore trailing blanks and which
shouldn't. In the case at hand, a closer look shows the problem:
=# explain verbose select c1,(c1 like c1) from t0;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on public.t0 (cost=0.00..43.00 rows=2200 width=6)
Output: c1, (c1 ~~ (c1)::text)
There is a "char ~~ text" operator but no "char ~~ char" operator,
so the parser coerces the right-hand "c1" to text --- which causes
stripping of its trailing blank --- and then applies ~~, which
treats the trailing blank in its left-hand argument as significant.
Yes, this is arguably inconsistent, but so are a lot of other char(N)
behaviors. Proposals to change anything about it have generally
failed on the grounds that (1) it's not very clear what would work
better and not just move the surprises around; (2) we risk breaking
applications that are expecting the current behaviors; and
(3) char(N) is a deprecated backwater that we shouldn't be putting
any effort into.
regards, tom lane
