ADQL-2.0 Erratum 4: NULL as valid value expression

Author: Grégory Mantelet

Date last changed: 2023-01-31

Date accepted: -


The in-development validator for ADQL (ivoa/lyonetia#16 (comment)) as described in the official standard document highlighted a miss since ADQL-2.0. NULL values are not allowed anywhere except in the constraint IS NULL. However, it is a valid value in any existing DBMS.

This Erratum aims to fix this miss by adding the NULL in the value expression definition.

Erratum Content

This Erratum changes the BNF grammar of ADQL-2.0, in the Appendix A, p.35, from:

<value_expression> ::= <numeric_value_expression> | <string_value_expression> | <geometry_value_expression>


<value_expression> ::= NULL | <numeric_value_expression> | <string_value_expression> | <geometry_value_expression>

Impact Assessment

All existing Database Management Systems (e.g. PostgreSQL, MySQL, SQLite, SQLServer, ...) allow NULL values in all places where a value can be provided.

DACHS and CADC already support it, and so, it should not be a problem for all existing services based on their TAP framework.

However, services based on VOLLT are impacted until a new version is released or if it has been forked and already fixed on this particular issue. Anyway, the amount of ADQL queries where a NULL has to be explicitly written (apart from the special constraint IS NULL) is extremely low. Hence, very few inconvenience is expected while waiting for a migration for a newer version resolving this issue. The next version of VOLLT will anyway embed ADQL-2.1, in which this problem is already fixed (see ivoa-std/ADQL#72).

Topic revision: r1 - 2023-01-31 - GregoryMantelet
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback