From: David M. Calascibetta <david@calascibetta.com>
To: 'Tom Lane' <tgl@sss.pgh.pa.us>
To: 'Mark Dilger' <mark.dilger@enterprisedb.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: RE: BUG #17258: Unexpected results in CHAR(1) data type
Date: Fri, 29 Oct 2021 18:10:00 -0500
Message-ID: <006c01d7cd1a$1a940130$4fbc0390$@calascibetta.com> (raw)
In-Reply-To: <758069.1635546207@sss.pgh.pa.us>
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>
<758069.1635546207@sss.pgh.pa.us>
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@sss.pgh.pa.us>
Sent: Friday, October 29, 2021 5:23 PM
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
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 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: david@calascibetta.com, tgl@sss.pgh.pa.us, mark.dilger@enterprisedb.com, pgsql-bugs@lists.postgresql.org
Subject: RE: BUG #17258: Unexpected results in CHAR(1) data type
In-Reply-To: <006c01d7cd1a$1a940130$4fbc0390$@calascibetta.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox