On Sep 24, 2009, at 6:24 AM, pg(at)thetdh(dot)com wrote:
> In a context using normalization, wouldn't you typically want to
> store a normalized-text type that could perhaps (depending on
> locale) take advantage of simpler, more-efficient comparison
That might be nice, but I'd be wary of a geometric multiplication of
text types. We already have TEXT and CITEXT; what if we had your NTEXT
(normalized text) but I wanted it to also be case-insensitive?
> Whether you're doing INSERT/UPDATE, or importing a flat text file,
> if you canonicalize characters and substrings of identical meaning
> when trivial distinctions of encoding are irrelevant, you're better
> off later. User-invocable normalization functions by themselves
> don't make much sense.
Well, they make sense because there's nothing else right now. It's an
easy way to get some support in, and besides, it's mandated by the SQL
> (If Postgres now supports binary- or mixed-binary-and-text flat
> files, perhaps for restore purposes, the same thing applies.)
Don't follow this bit.
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2009-09-24 15:59:09|
|Subject: Re: Unicode Normalization|
|Previous:||From: Marko Tiikkaja||Date: 2009-09-24 14:23:17|
|Subject: Re: Using results from INSERT ... RETURNING|