TAP questions

[Dobos, László]

I think I'll accept quoted and unquoted (if valid) table and column names on my side but use the exact form in the ADQL query I send to the TAP endpoint that matches the list returned by the TAP_SCHEMA views. It'll also solve capitalization issues (it any) but will certainly require to add some new logic to my parser/name resolver lib.

-L

-----Original Message-----
From: dal-bounces at ivoa.net [mailto:dal-bounces at ivoa.net] On Behalf Of 'Markus Demleitner'
Sent: Thursday, March 1, 2018 1:03 PM
To: dal at ivoa.net
Subject: Re: TAP questions

Hi Laszlo,

On Thu, Mar 01, 2018 at 12:14:18PM +0100, Dobos, László wrote:
> The remaining issue is identifier quoting and table naming (whether 
> schemaname.tablename is required or simply tablename is enough).
> This is why: SkyQuery will soon make it possible to write a 
> cross-match query that references TAP sources, as well databases 
> available locally at our db cluster. This requires parsing the queries 
> and resolve the identifiers against the TAP sources. Now, my parser 
> supports identifier quoting for both columns and table names, so I 
> only have unquoted identifiers after the parsing procedure and I have 
> to compose the ADQL queries bases on these that I can send to any TAP 
> endpoint that talks the standard. If can't be sure whether an endpoint 
> understands/requires/tolerates quoting or whether it combines schema 
> names with tables names I can't really make it work with just any 
> endpoint. Do you have any suggestions regarding this issue?

I don't think I understand the problem well enough to advise -- but
again: you cannot interoperably turn a regular to a delimited identifiers or meaningfully parse table references without knowing the DDL, so whatever scheme you end up with should just re-uses what it finds in tap_schema.tables.table_name in the eventual queries -- anything else will break sooner or later.

What that looks like to a user sending queries to your machine is a different question, and I agree it *might* not be the best idea to expose all the uglyness of delimited SQL identifiers, including their whacky relationship to regular identifiers, to your users.  In the end it's probably also up to what tools your users have to discover what tables are out there.

So -- how do you plan to let users write the remote table selection at this point?

          -- Markus