[TAP] case sensitivity of query
gerard.lemson at mpe.mpg.de
Tue Mar 3 08:58:28 PST 2009
> 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
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
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
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
> Please comment asap.
If the choice is between 1 and 2, I vote for 2.
More information about the dal