From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
cc: "<David@calascibetta.com>" <David@Calascibetta.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17258: Unexpected results in CHAR(1) data type
In-reply-to: <F04C22E4-C392-446E-840E-264F77397945@enterprisedb.com>
References: <17258-a7c164c5fb955221@postgresql.org>
 <19D58355-E7C3-47D7-9C87-51EC751AE2BB@enterprisedb.com>
 <003701d7ccfb$c2a85bb0$47f91310$@calascibetta.com>
 <0EE9669C-6E65-40E1-B492-F989F452DAC4@enterprisedb.com>
 <005501d7cd0b$9ba5d5f0$d2f181d0$@calascibetta.com>
 <F04C22E4-C392-446E-840E-264F77397945@enterprisedb.com>
Comments: In-reply-to Mark Dilger <mark.dilger@enterprisedb.com>
	message dated "Fri, 29 Oct 2021 14:36:08 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <758068.1635546207.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Oct 2021 18:23:27 -0400
Message-ID: <758069.1635546207@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/758069.1635546207%40sss.pgh.pa.us>
Precedence: bulk

Mark Dilger <mark.dilger@enterprisedb.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 rega=
rd.

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