| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | alex(at)purefiction(dot)net |
| Cc: | daniel(dot)colchete(at)gmail(dot)com, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: New to PostgreSQL, performance considerations |
| Date: | 2006-12-11 03:37:03 |
| Message-ID: | 20061211.123703.35677849.t-ishii@sraoss.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> That's not the whole story. UTF-8 and other variable-width encodings
> don't provide a 1:1 mapping of logical characters to single bytes; in
> particular, combination characters opens the possibility of multiple
> different byte sequences mapping to the same code point; therefore,
> string comparison in such encodings generally cannot be done at the
> byte level (unless, of course, you first acertain that the strings
> involved are all normalized to an unambiguous subset of your encoding).
Can you show me such encodings supported by PostgreSQL other
than UTF-8?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2006-12-11 04:04:38 | Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can |
| Previous Message | Chris | 2006-12-11 03:33:22 | Re: SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can helpe |