ADQL-2.0 Erratum 4: NULL as valid value expressionAuthor: Grégory Mantelet Date last changed: 2023-01-31 | ||||||||
Changed: | ||||||||
< < | Date accepted: - | |||||||
> > | Date accepted: 2023-04-05 | |||||||
Deleted: | ||||||||
< < | ||||||||
RationaleThe 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 ContentThis Erratum changes the BNF grammar of ADQL-2.0, in the Appendix A, p.35, from: | ||||||||
Deleted: | ||||||||
< < | ||||||||
into: | ||||||||
Deleted: | ||||||||
< < | ||||||||
Impact Assessment | ||||||||
Changed: | ||||||||
< < | All existing Database Management Systems (e.g. PostgreSQL, MySQL, SQLite, SQLServer, ...) allow NULL values in all places where a value can be provided. | |||||||
> > | 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. | ||||||||
Changed: | ||||||||
< < | 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). | |||||||
> > | 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). | |||||||
Deleted: | ||||||||
< < |
ADQL-2.0 Erratum 4: NULL as valid value expressionAuthor: Grégory Mantelet Date last changed: 2023-01-31 Date accepted: -RationaleThe 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 ContentThis Erratum changes the BNF grammar of ADQL-2.0, in the Appendix A, p.35, from:into:
Impact AssessmentAll existing Database Management Systems (e.g. PostgreSQL, MySQL, SQLite, SQLServer, ...) allowNULL 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). |