> I've gotten really tired of explaining to newbies why stuff involving
> char(n) fields doesn't work like they expect. Our current behavior is
> not valid per SQL92 anyway, I believe.
>
> I think there is a pretty simple solution now that we have pg_cast:
> we could stop treating char(n) as binary-equivalent to varchar/text,
> and instead define it as requiring a runtime conversion (which would
> be essentially the rtrim() function). The cast in the other direction
> would be assignment-only, so that any expression that involves mixed
> char(n) and varchar/text operations would be evaluated in varchar
> rules after stripping char's insignificant trailing blanks.
>
> If we did this, then operations like
> WHERE UPPER(charcolumn) = 'FOO'
> would work as a newbie expects. I believe that we'd come a lot closer
> to spec compliance on the behavior of char(n), too.
I am all for it. That would much more closely match what I would expect.
One alternate possible approach would maybe be to change the on-disk
representation to really be binary compatible and change the input
output and operator functions ? IIRC fixed width optimizations do not gain as
much as in earlier versions anyway. Then char(n) would have the benefit of
beeing trailing blank insensitive and having the optimal storage format.
Andreas
