On Wed, Jun 23, 2004 at 02:43:06PM +0900, Joel Matthew wrote:
> > We used to have some attempts at optimizing on the assumption that
> > char(n) fields were physically fixed-width, but we gave it up as a
> > bad job several major releases back ... it was never more than a
> > very marginal optimization anyway ...
>
> Does that mean that PostGreSQL fixes character width at thirty-two bits,
> or that it uses UTF-8, or that it just stores what it gets?
It'll use utf8 if configured to do so; it'll just store what it gets if
configured as SQL_ASCII (it isn't really ASCII); or it will convert from
the client encoding to the server encoding before storing, if they are
different.
> (Checked chapter 8.3 in the manual, didn't see the answer there. Not
> that I really want to know. With Unicode, trying to optimize record
> sizes for char/text fields is a little like trying to play Russian
> Roulette. Wait, is that no longer politically correct? Should it be
> called six-chamber roulette, now? Don't want to offend anyone.)
Of course, the optimization could have only worked on fixed-width
encodings (not utf8 -- maybe possible with utf32, but Postgres doesn't
support that AFAIK), but since current versions enable multibyte by
default there's really no point in trying.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I would rather have GNU than GNOT." (ccchips, lwn.net/Articles/37595/)
