Status: To Do
Fix Version/s: None
The TAP interface uses IVOA ADQL as the query language. Spatial queries are converted internally into scisql spatial calls and the scisql spatial queries are not part of the public interface. There are other scisql APIs that are wanted but we have to be careful and intentional about the way we make them public.
- Once we make a scisql function part of the public API, how long are we required to support that interface? Will people expect their queries from DR1 to work on DR2?
- If we change the Qserv backend from MariaDB to something else are we required to port the scisql interface or translate it?
- Should we have an explicit Rubin API that is like scisql but explicitly decoupled in the ADQL interface?
- Should we have a whitelist of extensions rather than making everything visible?
I feel that we should be intentional about what we do here since there can be long-term unforeseen ramifications if we let default behaviors through.
A whitelist is much better than allowing all scisql and UDFs to work – the spatial APIs should not be callable at all. An explicit rubin extension API is better than calling it scisql everywhere.
We also should work with the IVOA to extend ADQL to support the features we need. We have never tried to do that before so we can't blame IVOA for this. Does ADQL have an explicit extension mechanism?