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

> On Oct 29, 2021, at 2:26 PM, David M. Calascibetta  wrote:
> 
> OK. I have a work-around so I'm alright.

Glad to hear it.

> I agree, the behavior is nuts, and is inconsistent with every other RDBMS out there.

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.  If so, we should at least have a warning in the docs about that.  (We already have a warning about how char(n) behaves, but nothing I see about the behavior being non-compliant.)  But I'm wondering if other RDBMS products really differ in this regard?  Are you perhaps thinking about how varchar(n) works? 

> I was only reporting it to improve the product, but if you think this is appropriate behavior,
> I'm good with it.

I tend to think of char(n) as a misfeature and avoid using it.  Based on your experience with other RDBMSs, would you expect char(n) and varchar(n) to behave the same or to behave differently?  In postgres, they are different, and varchar(n) would behave more like you seem to want.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company