Master ticket for work/discussion on the ADQL dialect(s) and extensions supported by Rubin services.
Issues to consider:
- Dialect of ADQL supported by Qserv
- How to document it in a user-facing way? What can be captured just in /capabilities and what is deeper (e.g., Qserv limitations on the allowed arguments of CONTAINS() )?
- Are there currently-missing things we could support with limited effort? (AREA? CENTROID? COORD1/2?)
- What's too hard to contemplate? INTERSECTS?
- Generalization of documentation and error messages for ADQL limitations
- Much like Qserv, IRSA's TAP service has specific limitations on the use of the ADQL geometry primitives that cannot be captured by the /capabilities "<feature>" elements.
- Is there something we could do at IVOA level to standardize self-documentation?
- How errors related to the dialect are returned?
- How to return a pointer to user-level documentation on a service's limitations?
- Is TAP's existing /examples notion adequate if used in a consistent way?
- Additional functions provided by Rubin
- E.g., the non-spatial functions in scisql, like flux-to-mags conversions
- Do we intend to support these indefinitely?
- Can we get these advertised to the community? Can we use the existing IVOA registered-ADQL-extension mechanism?
- Are there spatial functions in scisql that don't have a reasonable ADQL equivalent? Should we try to get them into ADQL? Is this a prerequisite to blocking all the scisql spatial functions at the TAP layer?
- Is "scisql" an appropriate prefix or should we change it?
- Compatibility of query dialects between Qserv (Data Release tables and "published" user tables) and Postgres (PPDB tables, Consolidated DB, general user tables, "live ObsTAP")
- Can we make the non-spatial scisql functions available in Postgres?
From an Architecture team discussion:
We need to figure out what to do about the legacy of the sciSQL function set in Qserv, and how these will be represented as part of the public interface of the RSP TAP service.