Re: We have to support ANSI encoding...

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Johann Zuschlag" <zuschlag2(at)online(dot)de>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: We have to support ANSI encoding...
Date: 2005-09-20 14:10:30
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4CC2D95@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

> -----Original Message-----
> From: Johann Zuschlag [mailto:zuschlag2(at)online(dot)de]
> Sent: 20 September 2005 15:08
> To: Dave Page
> Cc: pgsql-odbc(at)postgresql(dot)org
> Subject: We have to support ANSI encoding...
>
> Hi Dave,
>
> I hope, that we can keep two drivers for the future. In fact
> we have to.
> Just note the excerpt of the PostgreSQL docs below:
>
>
> 20.1.2. Behavior
>
> Locale support influences the following features:
>
> * Sort order in queries using ORDER BY
> * The ability to use indexes with LIKE clauses
> * The |to_char| family of functions
>
> The drawback of using locales other than C or POSIX in
> PostgreSQL is its
> performance impact. It slows character handling and prevents ordinary
> indexes from being used by LIKE. For this reason use locales
> only if you
> actually need them.
>
>
>
> So because of performance reasons we don't want to use UTF-8
> always. The
> conclusion is that we must support both drivers.

Yeah, I'm pretty much resigned to that now - in fact, the only
alternative I can see is to convert incoming strings from the local
charset to ucs-2 in the *W functions of the Unicode driver - that seems
to be what the SQL Server driver does (it's configurable behaviour in
fact). Of course, that would reduce performance even further :-(

/D

Browse pgsql-odbc by date

  From Date Subject
Next Message Amarsh M 2005-09-21 01:55:49 Changing a database
Previous Message Johann Zuschlag 2005-09-20 14:07:46 We have to support ANSI encoding...