ADQL-2.0 Next

This topic collects proposals for modifications of the ADQL-2.0 specification in order to improve the next revision of the specification.

Following the guidelines to report and accept Errata to IVOA standards here you'll only find listed the proposed features and discussion for subsequents revisions of the this specification.

Errata tracking process for ADQL-2.0 can be found at ADQL-2_0-Errata page.

Proposed Features

Suggestion for revision of ADQL-2.0, in terms of errata content, clarifications and proposed new features, where initially collected in the TAP Implementation Notes wiki topic, later serial as an IVOA Note (its source available on volute), and then discussed at various Interoperability Meetings.

Before the Banff Interop (Northern Fall 2014) a page (vote on Madrid's splinter topics) was issued to try to reach some consensus.

With reference to the ADQL-2.1 internal WD (see [[ADQL][ADQL] topic), a session and splinter discussion took place at Sesto Interop. The outcome of that discussion (thank to notes from DaveMorris) is listed here as a starting point for further discussion:

• No-rewrite rule dropped. *Legacy restriction dropped to enable new functionality to go ahead.
• BOOLEAN data type will be added to ADQL-2.1
• Optional functions
  • Proposed text for describing how to handle optional features accepted in ADQL-2.1
• Acceptance criteria
  • The group will work together to define some acceptance criteria for optional and mandatory features. Accepted as task to do - first draft by Oct.
• Target platforms
  • The group will work together to collect details about the database platforms that are used to implement ADQL Which features are supported by which database platforms may form part of the acceptance criteria. Accepted as task to do - first draft by Oct.
• Generic user defined functions
  • Allow user defined functions returning geometry values
  • Accepted as mandatory core in ADQL-2.1.
• LOWER, ILIKE
  • Accepted as optional in ADQL-2.1
  • Some issues with indexing and platform support preventing them being mandatory.
• Set operators - UNION, INTERSECT, EXCEPT
  • Not as easy as originally thought.
  • Accepted as optional for ADQL-2.1 ( will probably only be implemented by experimental services)
• Hierarchical queries - WITH
  • Not as easy as originally thought
  • Accepted as optional for ADQL-2.1 ( will probably only be implemented by experimental services)
• CAST
  • Accepted as optional in ADQL-2.1
  • Probably mandatory in ADQL-3.0
• UCDCOL(’pos.eq.ra;meta.main’) => the first column with that UCD
  • Problems with implementation - proposal withdrawn.
• IN_UNIT
  • Simple unit transforms: dec + IN_UNIT(pmde,′ deg/yr′) ∗ 24.4
  • Proposed text description needs more detail.
  • Requires two independent implementations to be accepted as mandatory.
  • Accepted as optional in ADQL-2.1
  • Probably mandatory in ADQL-3.0
• Bitwise operators
  • BIT_AND, BIT_OR, BIT_XOR, BIT_NOT
  • Accepted as optional for ADQL-2.1.
• CROSSMATCH
  • Some questions to answer about what the function returns: “closest within match limit” or “all pairs up to sr”
  • Not accepted for ADQL-2.1 (yet).

• If LOWER, why not UPPER?
  • Accepted as optional in ADQL-2.1
• SUBSTRING, CONVERT, TRANSLATE, TRIM
  • To be discussed on the mailing list.
• ADQL data in TAPRegExt
  • Should the registration details for the ADQL optional features be moved from TAPRegExt to a 'std:ADQL' registry entry ?
• Duplcate columns
  • Questions raised about how we should cope with queries that produce columns with duplicate names. To be discussed on the mailing list.
• Deprecate REGION
  • To be discussed on the mailing list.
• Function overloading
  • Interval and 2D geom versions of CONTAINS etc. To be discussed on the mailing list.