ADQL2.0 Erratum 2: Mathematical Functions' Table issuesAuthor: Dave Morris Date last changed: 20180214  
Added:  
> >  Date accepted: 20180222  
RationaleIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread. Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar. Here follows what emerged as possible erratum content from those discussions. MOD function description Considering what current TAP1.0 services using ADQL implement and the usual SQL definition of the modulo operator: M % N = R with
RAND optional seed
ADQL BNF grammar (page 29 of ADQL2.0) reports the We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value. ROUND optional places number
ADQL BNF grammar (pages 2930 of ADQL2.0) reports the We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.". TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL2.0) reports the We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
Erratum ContentThis erratum changes the description of the mod, rand, round and truncate function in Table 1 on page 8 of the ADQL2.0 recommendation from mod(x, y) Returns the remainder of y/x. rand(x) Returns a random value between 0.0 and 1.0, where x is a seed value. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. truncate(x, n) Returns the result of truncating the argument x to n decimal places. to
mod(x, y) Returns the remainder of x/y. rand(x) Returns a random value between 0.0 and 1.0. The optional argument, originally intended to provide a random seed, has undefined semantics. Query writers are advised to use the form without the argument. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. The integer n is optional and its value should default to 0. truncate(x, n) Returns the result of truncating the argument x to n decimal places. The integer n is optional and its value should default to 0.
Impact AssessmentThe changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issues, all of them simply require some explicit wording in the description to follow the grammar constraints. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.
<

ADQL2.0 Erratum 2: Mathematical Functions' Table issues  
Changed:  
< <  Author: DAL WG  
> >  Author: Dave Morris  
Date last changed: 20180214
RationaleIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread. Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar. Here follows what emerged as possible erratum content from those discussions. MOD function description Considering what current TAP1.0 services using ADQL implement and the usual SQL definition of the modulo operator: M % N = R with
RAND optional seed
ADQL BNF grammar (page 29 of ADQL2.0) reports the We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value. ROUND optional places number
ADQL BNF grammar (pages 2930 of ADQL2.0) reports the We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.". TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL2.0) reports the We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
Erratum ContentThis erratum changes the description of the mod, rand, round and truncate function in Table 1 on page 8 of the ADQL2.0 recommendation from mod(x, y) Returns the remainder of y/x. rand(x) Returns a random value between 0.0 and 1.0, where x is a seed value. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. truncate(x, n) Returns the result of truncating the argument x to n decimal places. to
mod(x, y) Returns the remainder of x/y. rand(x) Returns a random value between 0.0 and 1.0. The optional argument, originally intended to provide a random seed, has undefined semantics. Query writers are advised to use the form without the argument. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. The integer n is optional and its value should default to 0. truncate(x, n) Returns the result of truncating the argument x to n decimal places. The integer n is optional and its value should default to 0.
Impact AssessmentThe changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issues, all of them simply require some explicit wording in the description to follow the grammar constraints. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.
<

ADQL2.0 Erratum 2: Mathematical Functions' Table issuesAuthor: DAL WG  
Changed:  
< <  Date last changed: 20171009  
> >  Date last changed: 20180214  
RationaleIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread. Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar. Here follows what emerged as possible erratum content from those discussions. MOD function description Considering what current TAP1.0 services using ADQL implement and the usual SQL definition of the modulo operator: M % N = R with
RAND optional seed
ADQL BNF grammar (page 29 of ADQL2.0) reports the We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value. ROUND optional places number
ADQL BNF grammar (pages 2930 of ADQL2.0) reports the We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.". TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL2.0) reports the We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
Erratum Content  
Changed:  
< <  Table 1 on page 8 of the ADQL2.0 recommendation reports the following descriptions for the hereby discussed mathematical functions:
 
> >  This erratum changes the description of the mod, rand, round and truncate function in Table 1 on page 8 of the ADQL2.0 recommendation from
mod(x, y) Returns the remainder of y/x. rand(x)  
Added:  
> >  Returns a random value between 0.0 and 1.0, where x is a seed value. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. truncate(x, n) Returns the result of truncating the argument x to n decimal places.  
Changed:  
< <  This erratum amends these descriptions, given what's discussed in the rationale of this erratum, substituting them with the following ones:
 
> >  to
mod(x, y) Returns the remainder of x/y. rand(x) Returns a random value between 0.0 and 1.0. The optional argument, originally intended to provide a random seed, has undefined semantics.  
Added:  
> >  Query writers are advised to use the form without the argument. round(x, n) Rounds double value x to n number of decimal places, with the default being to round to the nearest integer. To round to the left of the decimal point, a negative number should be provided. The integer n is optional and its value should default to 0. truncate(x, n) Returns the result of truncating the argument x to n decimal places. The integer n is optional and its value should default to 0.  
Impact AssessmentThe changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issues, all of them simply require some explicit wording in the description to follow the grammar constraints. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.
<

ADQL2.0 Erratum 2: Mathematical Functions' Table issuesAuthor: DAL WG  
Changed:  
< <  Date last changed: 20170928  
> >  Date last changed: 20171009  
RationaleIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread. Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar. Here follows what emerged as possible erratum content from those discussions. MOD function description  
Changed:  
< <  Considering what current TAP1.0 services using ADQL and the mathematical description of the modulo operator where  
> >  Considering what current TAP1.0 services using ADQL implement and the usual SQL definition of the modulo operator:  
M % N = R
with
RAND optional seed
ADQL BNF grammar (page 29 of ADQL2.0) reports the We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value. ROUND optional places number
ADQL BNF grammar (pages 2930 of ADQL2.0) reports the We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.". TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL2.0) reports the We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
Erratum ContentTable 1 on page 8 of the ADQL2.0 recommendation reports the following descriptions for the hereby discussed mathematical functions:
This erratum amends these descriptions, given what's discussed in the rationale of this erratum, substituting them with the following ones:
Impact AssessmentThe changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issues, all of them simply require some explicit wording in the description to follow the grammar constraints. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.
<

ADQL2.0 Erratum 2: Mathematical Functions' Table issuesAuthor: DAL WG Date last changed: 20170928
RationaleIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread. Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar. Here follows what emerged as possible erratum content from those discussions. MOD function description Considering what current TAP1.0 services using ADQL and the mathematical description of the modulo operator where M % N = R with
RAND optional seed
ADQL BNF grammar (page 29 of ADQL2.0) reports the We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value. ROUND optional places number
ADQL BNF grammar (pages 2930 of ADQL2.0) reports the We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.". TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL2.0) reports the We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
Erratum ContentTable 1 on page 8 of the ADQL2.0 recommendation reports the following descriptions for the hereby discussed mathematical functions:
This erratum amends these descriptions, given what's discussed in the rationale of this erratum, substituting them with the following ones:
Impact Assessment  
Changed:  
< <  The changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issue, all of them simply require some explicit wording in the description to follow the grammar constrains. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.  
> >  The changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issues, all of them simply require some explicit wording in the description to follow the grammar constraints. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.  
<

ADQL2.0 Erratum 2: Mathematical Functions' Table issuesAuthor: DAL WG  
Changed:  
< <  Date last changed: 20170526  
> >  Date last changed: 20170928  
RationaleIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread. Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar. Here follows what emerged as possible erratum content from those discussions. MOD function description Considering what current TAP1.0 services using ADQL and the mathematical description of the modulo operator where M % N = R with
RAND optional seed
ADQL BNF grammar (page 29 of ADQL2.0) reports the We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value. ROUND optional places number
ADQL BNF grammar (pages 2930 of ADQL2.0) reports the We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.". TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL2.0) reports the We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
Erratum ContentTable 1 on page 8 of the ADQL2.0 recommendation reports the following descriptions for the hereby discussed mathematical functions:
This erratum amends these descriptions, given what's discussed in the rationale of this erratum, substituting them with the following ones:
 
Changed:  
< < 
 
> > 
 
Added:  
> >  optional argument, originally intended to provide a random seed, has undefined semantics. Query writers are advised to use the form without the argument.*  
Impact AssessmentThe changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issue, all of them simply require some explicit wording in the description to follow the grammar constrains. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.
<

ADQL2.0 Erratum 2: Mathematical Functions' Table issuesAuthor: DAL WG Date last changed: 20170526
RationaleIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread. Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar. Here follows what emerged as possible erratum content from those discussions. MOD function description Considering what current TAP1.0 services using ADQL and the mathematical description of the modulo operator where M % N = R with
 
Deleted:  
< <  
The definition of mod(x, y) in ADQL2.0 should be amended to "Returns the remainder of x/y". It should also be made clear, maybe in a future revision, to follow the above rules for the remainder and its sign.
RAND optional seed
ADQL BNF grammar (page 29 of ADQL2.0) reports the We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value. ROUND optional places number
ADQL BNF grammar (pages 2930 of ADQL2.0) reports the We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.". TRUNCATE optional places number
ADQL BNF grammar (page 30 of ADQL2.0) reports the We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
Erratum ContentTable 1 on page 8 of the ADQL2.0 recommendation reports the following descriptions for the hereby discussed mathematical functions:  
Changed:  
< < 
 
> > 
 
Deleted:  
< <  
This erratum amends these descriptions, given what's discussed in the rationale of this erratum, substituting them with the following ones:  
Changed:  
< < 
 
> > 
 
Deleted:  
< <   
Changed:  
< <  Impact Assesment  
> >  Impact Assessment  
The changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issue, all of them simply require some explicit wording in the description to follow the grammar constrains. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.
<

 
Changed:  
< <  ADQL2.0 Erratum 2  Mathematical functions' Table issues  
> >  ADQL2.0 Erratum 2: Mathematical Functions' Table issues  
Changed:  
< <  IVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread.  
> >  Author: DAL WG  
Changed:  
< <  Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar.  
> >  Date last changed: 20170526  
Changed:  
< <  Erratum Content  
> >  Rationale  
Changed:  
< <  Table 1 on page 8 of the ADQL2.0 recommendation reports  
> >  IVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread.  
Deleted:  
< < 
 
Changed:  
< <  The descriptions reported in the above table are ambiguous with respect to the ADQL grammar or are conflicting with SQL definitions.  
> >  Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar.  
Deleted:  
< <  Issue 1 seems to conflict with SQL (92, 2003) definitions and, as well, the behaviour of the existing TAP services, suggesting that x and y should be swapped in the function description. Issue 2 description does not report x to be optional. Issues 3 & 4 descriptions do not report that n is optional and that it should default to 0.  
Changed:  
< <  Rationale  
> >  Here follows what emerged as possible erratum content from those discussions.  
Changed:  
< <  (issue 1) MOD function description  
> >  MOD function description  
Deleted:  
< <  Considering what current TAP services using ADQL and the mathematical description of the modulo operator where  
Added:  
> >  Considering what current TAP1.0 services using ADQL and the mathematical description of the modulo operator where  
M % N = R
with
 
Changed:  
< <  The definition of mod(x, y) in ADQL2.0 should be amended to "Returns the remainder of x/y". It should also be made clear, maybe in a future revision, to follow the above rules for the remainder and its sign.  
> >  The definition of mod(x, y) in ADQL2.0 should be amended to "Returns the remainder of x/y". It should also be made clear, maybe in a future revision, to follow the above rules for the remainder and its sign.  
Changed:  
< <  (issue 2) RAND optional seed  
> >  RAND optional seed  
Deleted:  
< <  ADQL BNF grammar (page 29 of ADQL2.0) reports the  
Added:  
> >  ADQL BNF grammar (page 29 of ADQL2.0) reports the unsigned_integer x to be an optional argument (the seed) to the random mathematical function. This is not made explicit in the description in Table 1.  
We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value.  
Changed:  
< <  (issue 3) ROUND optional places number  
> >  ROUND optional places number  
Deleted:  
< <  ADQL BNF grammar (pages 2930 of ADQL2.0) reports the  
Added:  
> >  ADQL BNF grammar (pages 2930 of ADQL2.0) reports the signed_integer n of ROUND(x, n) to be an optional argument. This signed integer number of places to round the value of x to is not made explicit to be optional in Table 1 description. Also, as per SQL standard, it should default to 0 when not explicitly present.  
We suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".  
Changed:  
< <  (issue 4) TRUNCATE optional places number  
> >  TRUNCATE optional places number  
Deleted:  
< <  ADQL BNF grammar (page 30 of ADQL2.0) reports the  
Added:  
> >  ADQL BNF grammar (page 30 of ADQL2.0) reports the signed_integer n of TRUNCATE(x, n) to be an optional argument. This signed integer number of places to truncate the value of x to is not made explicit to be optional in Table 1 description. Also, as per SQL standard, it should default to 0 when not explicitly present.  
We suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".  
Added:  
> > 
Erratum ContentTable 1 on page 8 of the ADQL2.0 recommendation reports the following descriptions for the hereby discussed mathematical functions:
 
Impact AssesmentThe changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issue, all of them simply require some explicit wording in the description to follow the grammar constrains. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.
<

 
Changed:  
< <  ADQL2.0 Erratum 2  MOD function description  
> >  ADQL2.0 Erratum 2  Mathematical functions' Table issues  
Changed:  
< <  IVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function.  
> >  IVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. Discussion went on also on this other thread.  
Added:  
> >  Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL2.0 grammar.  
Erratum ContentTable 1 on page 8 of the ADQL2.0 recommendation reports  
Changed:  
< < 
 
> > 
 
Added:  
> > 
 
Added:  
> >  The descriptions reported in the above table are ambiguous with respect to the ADQL grammar or are conflicting with SQL definitions. Issue 1 seems to conflict with SQL (92, 2003) definitions and, as well, the behaviour of the existing TAP services, suggesting that x and y should be swapped in the function description. Issue 2 description does not report x to be optional. Issues 3 & 4 descriptions do not report that n is optional and that it should default to 0.  
Rationale  
Added:  
> >  (issue 1) MOD function description  
Considering what current TAP services using ADQL and the mathematical description of the modulo operator where
M % N = R with
The definition of mod(x, y) in ADQL2.0 should be amended to "Returns the remainder of x/y". It should also be made clear, maybe in a future revision, to follow the above rules for the remainder and its sign.  
Added:  
> >  (issue 2) RAND optional seedADQL BNF grammar (page 29 of ADQL2.0) reports theWe suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value.
(issue 3) ROUND optional places numberADQL BNF grammar (pages 2930 of ADQL2.0) reports theWe suggest to amend the description of round(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".
(issue 4) TRUNCATE optional places numberADQL BNF grammar (page 30 of ADQL2.0) reports theWe suggest to amend the description of truncate(x, n) in Table 1 by adding a final sentence reading "The integer n is optional and its value should default to 0.".  
Impact Assesment  
Changed:  
< <  The change proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services shows they already act following the behaviour here above described. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same bahaviour too. See the mail thread referenced in the introduction of this page for details.  
> >  The changes proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services show they already act following the behaviour here above described for the modulo function, while for the remaining 3 issue, all of them simply require some explicit wording in the description to follow the grammar constrains. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. See the mail threads referenced in the introduction of this page for details.  
<

ADQL2.0 Erratum 2  MOD function descriptionIVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function.
Erratum ContentTable 1 on page 8 of the ADQL2.0 recommendation reports
RationaleConsidering what current TAP services using ADQL and the mathematical description of the modulo operator where M % N = R with
The definition of mod(x, y) in ADQL2.0 should be amended to "Returns the remainder of x/y". It should also be made clear, maybe in a future revision, to follow the above rules for the remainder and its sign.
Impact AssesmentThe change proposed by this erratum should impact no existing IVOA resource. Checks against the major TAP services shows they already act following the behaviour here above described. Checks against a choice of RDBMSes (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same bahaviour too. See the mail thread referenced in the introduction of this page for details.
<
