[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vQuery LIKE question




John Stracke wrote:

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. 


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.



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. 


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.