Re: Fixed length data types issue

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Gregory Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Martijn van Oosterhout <kleptog(at)svana(dot)org>
Subject: Re: Fixed length data types issue
Date: 2006-09-14 17:35:14
Message-ID: 200609141735.k8EHZEx27517@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
> Gregory Stark wrote:
> >
> > Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> >
> > > Gregory Stark wrote:
> > >>
> > >> Well "char" doesn't have quite the same semantics as CHAR(1). If that's the
> > >> consensus though then I can work on either fixing "char" semantics to match
> > >> CHAR(1) or adding a separate type instead.
> > >
> > > What semantics?
> >
> > The main bit that comes to mind is 32::CHAR(1) give you '3' but 32::"char"
> > gives you ' '.
> >
> > Really it makes more sense if you think of "char" is a 1 byte integer type
> > with some extra text casts and operators to make C programmers happy, not a 1
> > byte character type.
>
> One very nifty trick would be to fix "char" to act as CHAR(), and map
> CHAR(1) automatically to "char".

Sorry, probably a stupid idea considering multi-byte encodings. I
suppose it could be an optimization for single-byte encodings, but that
seems very limiting.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 2006-09-14 18:04:58 Re: New version of money type
Previous Message Joshua D. Drake 2006-09-14 17:33:19 Re: New version of money type