From: | Tim Uckun <tim(at)diligence(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Simple Question: Case sensitivity - Performance? |
Date: | 2000-12-11 18:37:51 |
Message-ID: | 4.2.0.58.20001211113115.00ac9418@mail.diligence.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 03:43 PM 12/11/2000 +0000, martin(dot)chantler(at)convergys(dot)com wrote:
>As an aside in DB2 there is the concept of a shared weight index which
>depending
>on
>locale lumps lower/upper case characters together so that you don't have to
>include
>an UPPER in the SQL - and it will use the index. Perhaps postgres can also
>work
>this way?
MS-SQL server and sybase both have an option which allows you to do case
insensitive queries as a database setting. I know that this is not standard
SQL behavior but considering that MS access also treats all of it's queries
in a case insensitive matter I think it makes sense to try and accommodate
people migrating from SQL server/ sybase or up sizing from access.
I have thought of doing one of the following.
1) overload the = operator for varchar, text,bpchar etc. so that it
compares insensitively. Would this seriously disrupt the database? How
would it effect group bys and order bys?
2) Dig into the code and change the varlena functions so that they do a
upper before the strcmp. Again how seriously this would disrupt the rest of
the system.
3) Create a case insensitive locale. Well this certainly seems the cleanest
approach and is unlikely to break the database in any way. I am suprised
nobody has done this yet. Is there a document which describes how to create
locales?
:wq
Tim Uckun
Due Diligence Inc. http://www.diligence.com/ Americas Background
Investigation Expert.
If your company isn't doing background checks, maybe you haven't considered
the risks of a bad hire.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-12-11 18:46:41 | Re: Great Bridge PostgreSQL products and services |
Previous Message | Ned Lilly | 2000-12-11 18:17:51 | Great Bridge PostgreSQL products and services |