pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Daniel van Ham Colchete <daniel.colchete@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: New to PostgreSQL, performance considerations
Date: Mon, 11 Dec 2006 08:32:43 -0200
Message-ID: <8a0c7af10612110232y2fb416ffpdfa70f1b492388ae@mail.gmail.com> (raw)
In-Reply-To: <60515F4F-51D7-4F2F-A4A0-E59E219DF16A@purefiction.net>
References: <8a0c7af10612101141n2c7727c3r2f92345753960808@mail.gmail.com>
	<430d92a20612101336r3de8862coe618277fccb4006a@mail.gmail.com>
	<8a0c7af10612101702i49b5a533v4a2300d90d9dae6b@mail.gmail.com>
	<430d92a20612101718o239dbf9dg990e784c17bf175a@mail.gmail.com>
	<8a0c7af10612101747j33b09ddft21d3341cc95dfaf5@mail.gmail.com>
	<60515F4F-51D7-4F2F-A4A0-E59E219DF16A@purefiction.net>

On 12/11/06, Alexander Staubo <alex@purefiction.net> wrote:
> On Dec 11, 2006, at 02:47 , Daniel van Ham Colchete wrote:
>
> > I never understood what's the matter between the ASCII/ISO-8859-1/UTF8
> > charsets to a database. They're all simple C strings that doesn't have
> > the zero-byte in the midlle (like UTF16 would) and that doesn't
> > require any different processing unless you are doing case insensitive
> > search (them you would have a problem).
>
> 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).
>
> PostgreSQL's use of strings is not limited to string comparison.
> Substring extraction, concatenation, regular expression matching, up/
> downcasing, tokenization and so on are all part of PostgreSQL's small
> library of text manipulation functions, and all deal with logical
> characters, meaning they must be Unicode-aware.
>
> Alexander.
>

You're right. I was thinking only about my cases that takes the
Unicode normatization for granted and doesn't use
regexp/tokenization/...
Thanks

Best
Daniel



view thread (124+ messages)  latest in thread

Message-ID: <8a0c7af10612110232y2fb416ffpdfa70f1b492388ae@mail.gmail.com>
Permalink:  ../8a0c7af10612110232y2fb416ffpdfa70f1b492388ae@mail.gmail.com/
Also on:    postgresql.org/message-id/8a0c7af10612110232y2fb416ffpdfa70f1b492388ae@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: daniel.colchete@gmail.com
  Subject: Re: New to PostgreSQL, performance considerations
  In-Reply-To: <8a0c7af10612110232y2fb416ffpdfa70f1b492388ae@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox