Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <870515282.364881269010768003.JavaMail.jira@brutus.apache.org>
Date: Fri, 19 Mar 2010 14:59:28 +0000 (UTC)
From: "Kim Haase (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1748) Global case insensitive setting
In-Reply-To: <6394134.1156285453855.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-1748?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1284=
7391#action_12847391 ]=20

Kim Haase commented on DERBY-1748:
----------------------------------

Thank you, Gunnar, that should give me enough to go on -- the dev guide tex=
t explains what the strengths mean. I should note that in the devgulde.text=
 one, in my locale, a character in the following came across as a diamond w=
ith a question mark in it --

as well as "a" and "=EF=BF=BD".

I'll have to see if there is some locale-neutral way of putting such charac=
ters in the manuals.

> Global case insensitive setting
> -------------------------------
>
>                 Key: DERBY-1748
>                 URL: https://issues.apache.org/jira/browse/DERBY-1748
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Terry
>         Attachments: collation-strength-1.diff, collation-strength-2.diff=
, collation-strength.diff, devguide.txt, refman.txt, remove_dead_code.diff
>
>
> By default MySQL is case insensitive in its string comparisons, as you ca=
n see from the MySQL docs shown below. Similar functionality is available i=
n Sybase iAnywhere and in SQLServer. I'd like the same to be true for Derby=
.
> What, I wonder, are chances of that?
> I am aware that functions could be used to force comparisons in upper cas=
e but that subverts the indexes and makes searches unacceptably long.
> If you were to ask people you might find that this is a feature whose abs=
cence is causing many to look elsewhere.
> thanks for all the great work,
> Terry
> The MySQL Docs say:
> -------- start quote
>  By default, MySQL searches are not case sensitive (although there are so=
me character sets that are never case insensitive, such as czech). This mea=
ns that if you search with col_name LIKE 'a%', you get all column values th=
at start with A or a. If you want to make this search case sensitive, make =
sure that one of the operands has a case sensitive or binary collation. For=
 example, if you are comparing a column and a string that both have the lat=
in1 character set, you can use the COLLATE operator to cause either operand=
 to have the latin1_general_cs or latin1_bin collation. For example:
> col_name COLLATE latin1_general_cs LIKE 'a%'
> col_name LIKE 'a%' COLLATE latin1_general_cs
> col_name COLLATE latin1_bin LIKE 'a%'
> col_name LIKE 'a%' COLLATE latin1_bin
> If you want a column always to be treated in case-sensitive fashion, decl=
are it with a case sensitive or binary collation. See Section 13.1.5, "CREA=
TE TABLE Syntax".=20
>     By default, the search is performed in case-insensitive fashion. In M=
ySQL 4.1 and up, you can make a full-text search by using a binary collatio=
n for the indexed columns. For example, a column that has a character set o=
f latin1 can be assigned a collation of latin1_bin to make it case sensitiv=
e for full-text searches.
> --------------- end quote

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.