Re: [HACKERS] Parser bug (?)

All points are well taken, but I will object to the "700%" number. Still
misleading imho. But that's not the point...

> I didn't object to removing char2, char4, and the other fixed-width
> special character types, but I think that plain char has applications
> that justify leaving it in there. I'm willing to consider giving
> it a different name if you really insist that char should be char(1)
> (though I don't agree with that).

The SQL92 standard sez that char is shorthand for char(1). Trying to
make the behavior of char vs char() *completely* transparent as called
for in the standard is one reason why I squashed them together from a
user's point of view. I only left char in the mix because it is used
internally in Postgres system tables and I didn't want to open that can
of worms (and don't intend to, so don't panic).

I shouldn't hide behind the SQL92 standards argument, since there are
some parts of the standard which are so hideous that they should be
ignored. But I'm not certain this is one of them.

Another detail: we would need to figure out how to do locale and
multibyte support for this "char" type to allow equivalence with
multibyte char(1). Not sure how to do that since this type *is* used
internally and probably can't be resized like that.

Speaking of which, are you or Bruce (or anyone else) thinking of testing
the unsigned int vs size_t for the Size typedef recently mentioned by
Oliver? Can we count on all platforms to have size_t defined? If so, we
could consider adding it in for v6.4.1. I'm currently working on getting
min() and max() to work with string types, but could drop that to polish
things for a v6.4.1 release.

- Tom