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

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

In every other rdbms, if it's fixed length character, values will always be that fixed length.
PG behaves that way unless the value is blank. I believe this is in violation of the spec,
which is why I reported it. Even the PG doc says it will pad with blanks. It does not give
an exception for blank values.



> 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
expectchar(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. 

They should behave the same, in that if I insert a blank into a char(1) column, it should store a blank value.
If I insert a blank into a varchar(1) column, it should store a blank value.  Fixed length characters would pad
on the right, but it should not distort the value I entered in any other way. In this case, I enter a blank value and
PG removes it.  That is not appropriate behavior.