Re: UTF8 conversion differences from v8.1.3 to v8.1.4

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Eric Faulhaber <ecf(at)goldencode(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: UTF8 conversion differences from v8.1.3 to v8.1.4
Date: 2006-07-20 11:51:43
Message-ID: 20060720115143.GA26339@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jul 19, 2006 at 06:06:08PM -0400, Eric Faulhaber wrote:
> Martijn van Oosterhout wrote:
> > On Wed, Jul 19, 2006 at 05:24:53PM -0400, Eric Faulhaber wrote:
> >> OK, but now that this "feature" has been removed in 8.1.4, how is this
> >> supposed to be handled, given that we don't control what string data
> >> we're handed? How does psql deal with it?
> >
> > Well, bytea handles null like it always has. There must be a way to you
> > to store strings into bytea columns... But I only have a vague
> > understanding of why bytea won't work for you...
>
> Collation, for one. Our runtime is extremely sensitive to the order in
> which records are read, to the point where I've created a custom locale
> just for the PostgreSQL cluster.
>
> Then there's case sensitivity, being able to use string functions in
> SQL, etc., etc. Bottom line, these are valid strings, so we need to
> treat them as such.

Well, there's a really nasty workaround: create a cast from bytea to
text which doesn't change the value. This will get your data into the
database without any encoding checks at all. Ofcourse, you're then
responsible for any problems caused down the line...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Sven Willenberger 2006-07-20 14:13:35 Re: psql seems to hang during delete query
Previous Message Andreas Kretschmer 2006-07-20 09:57:45 Re: timestamp and calculations.