> >> If we were going to do that I think we'd be better off making a
> >> new type and leaving "char" alone.
>
> > You won't hear any disagreements from me on this one. I've
> > sufficiently abused "char" as a 1 byte storage field and would
> > love to see an int1 or tinyint datatype added to cover this
> > situation. -sc
>
> That's been discussed before. I think it was shelved until we
> figure out a reasonably clean solution to the existing mess with
> assigning the most useful datatypes to integer constants (the "you
> need to cast" set of problems). Throwing an additional integer type
> into the stew right now would just make things worse :-(
Hrm, yes and no. It'd make things worse here on the lists in terms of
the FAQ for casting/index usage, etc. By the same token, I'd rather
have an int1 and cast for the time being, then when a solution does
pop into existence, I'll slowly either begin removing the casts or
just stop using them in future development. In the meantime, I'll
have a formally supported int1 storage type that isn't "char".
-sc
--
Sean Chittenden
