| From: | Sean Chittenden <sean(at)chittenden(dot)org> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, CSN <cool_screen_name90001(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: int1? | 
| Date: | 2003-10-14 18:48:23 | 
| Message-ID: | 20031014184823.GB21028@perrin.nxad.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
> >> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vhikida | 2003-10-14 18:57:57 | Re: Question | 
| Previous Message | pw | 2003-10-14 18:39:50 | Re: converting varchar date strings to date |