Subject: Re: vQuery LIKE question

From: "John Stracke" <[email-masked]>
Date: Tue, 12 Mar 2002 14:03:04 -0500

>I would think that 'a' would not match any of à á â ã ä or å.
>As we modeled it after the SQL LIKE. It should do the same.

I don't know that that follows.  SQL doesn't really handle Unicode, for 
example; but CAP needs to.

>I am also not sure that those can be assumed to mean that they
>are simply accented versions of the character in all languages.

It might be that whether it matches should depend on the locale.

On the other hand, it might be that we should match strictly, on the 
theory that then a CUA has a more precise building block to work with.  If 
I'm using a language that has, say, "foo" and "föö", and they're completely different words, then maybe I want to be able 
to search for "LIKE 'foo%'" and not get strings starting with "föö".  If I want both, I can always OR them.  That puts the locale 
awareness in the CUA, where it belongs.

So...yeah, I think we should specify an exact character match for now; if 
we need something more powerful later, we can add an extension.  (It might 
not need locale-aware matches, either; it might be that full regexp 
support would be enough.)

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|Unless. -- The Lorax                                    |
\========================================================/

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Mar 2002 14:10:51 -0700

> example; but CAP needs to.

SQL-92 can handle 8-bit charsets and various locales. In fact it has
a very extensive description of charset issues. Newer versions
have more support.

	SQL-92:
	
	CHARACTER_SETS, CHARACTER_SETS_CHECK_REFERANCE_COLLATIONS,
	CHARACTER_SETS_DEFAULT_COLATE,
	CHARACTER_SETS_DEFAULT_COLLATENAME_NOT_NULL,
	CHARACTER_SETS_DEFAULT_COLLATE_SCHEMA_NOT_NULL,
	CHARACTER_SETS_FORGEIGN_KEY_SCHEMA,
	CHARACTER_SET_CATALOG,CHARACTER_SET_NAME, CHARACTER_SET_SCHEMA,
	DEFAULT_COLLATE_CATALOG, DEFAULT .....

Some implementations do not support locals - get a new SQL supplier.

> theory that then a CUA has a more precise building block to work with.

We should always match on the LOCALE settings. If the LC_COLLATE
setting in the locale definition match, then we match. It's really
out of scope for CAP to specify the details. We just need to say
that the results depend on the LOCALE (not charset).

I had posted a proposal for a CS to advertise its locals as a MUST.
Where BEEP says that it is a MAY. I think that that simply means
that we MAY say it is a MUST :-)

Then if we were to add (later) the 2nd part of my proposal which
allows a CUA to specify the locale for the query, restricted to the set 
supplied by the CS at greeting time; then the CU will get the set
they would expect to get.