> >> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
