[TAP] case sensitivity of query

[Gerard]

Hi Pat

> ...
> I see two possible options that would make things work:
> 
> 1. The service exposes the correct case-sensitive names and 
> TAP clients do not modify these names in any way. This is 
> less extreme than what is stated in
> 2.3.4 but in the same spirit (which is explained in that 
> subsection). We could modify the text to say that the query 
> is not case sensitive except in this one respect. 
> 
What should happen if clients *do* use table/column names with different
case.
Should the TAP service report an error? Also for case-insensitive databases?

> 2. The service has to accept a completely non-case query and 
> if the backend db is case-sensitive the service has to map 
> the table and column names from the metadata as necessary to 
> make it work. This would get harder if the service really 
> used case to distinguish things (like columns ra,dec,RA,DEC) 
> but could still be done as long as the column names in the 
> exposed metadata are unique. 
> I don't know if anyone has/would make a database schema that way...
> 
That would be very bad design indeed.

> Note: It should be noted that the current metadata (TBD) plan 
> is that the service exposes the fully-qualified table name 
> (e.g. with as many of the catalog and schema specified as are 
> needed for the query to be correct) and the client is 
> expected to use the fully-qualified table names "as-is" and 
> not to parse them to get at these constructs. This greatly 
> simplifies the metadata (esp. the XML schema, I understand) 
> and works fine. Thus, clients are already supposed to use use 
> table names "as-is" and #1 above just extends it to include 
> case and apply to column names.
> 
> Note: For TAP implementors where the DB is not case 
> sensitive, neither of these effect you, but #1 marginally 
> effects the client. 
> 
That depends on what the reaction should be in case clients do not use the
same
case as in the metadata. See above.


Btw, I think ni my comments I mentioned two types of case sensitivity.
One of table/column names etc, another of string literals.

At least my SQLServer databases are case-insensitive regarding string
literals.
i.e. 
  select * from coords where coordsystem='icrs'
will return same as 
  select * from coords where coordsystem='ICRS'

Though a postgres installation is not.
(Both are case-insensitive regarding table and column names.)
There are arguments why case-insensitivity for string literals is indeed a
good thing.


> Please comment asap.
If the choice is between 1 and 2, I vote for 2.

Gerard