Checks against a choice of RDBMS-es (PostgreSQL, MySQL, MariaDB, Apache Derby, HyperSQL and Oracle) shows the same behaviour too. 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. The changes proposed by this erratum should impact no existing IVOA resource. The integer n is optional and its value should default to 0.
Point, a negative number should be provided. Query writers are advised to use the form without the argument. Originally intended to provide a random seed, has undefined semantics. Returns a random value between 0.0 and 1.0. Returns the result of truncating the argument x to n decimal places. Rounds double value x to n number of decimal places, with the defaultīeing to round to the nearest integer. Returns a random value between 0.0 and 1.0, where x is a seed value. This erratum changes the description of the mod, rand, round and truncate function in Table 1 on page 8 of the ADQL-2.0 recommendation from 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.". Also, as per SQL standard, it should default to 0 when not explicitly present. This signed integer number of places to truncate the value of x to is not made explicit to be optional in Table 1 description. 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.".ĪDQL BNF grammar (page 30 of ADQL-2.0) reports the signed_integer n of TRUNCATE(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. We suggest to amend the description changing the final "where x is a seed" into "where x is an optional seed" value.ĪDQL BNF grammar (pages 29-30 of ADQL-2.0) reports the signed_integer n of ROUND(x, n) to be an optional argument. This is not made explicit in the description in Table 1. It should also be made clear, maybe in a future revision, to follow the above rules for the remainder and its sign.ĪDQL BNF grammar (page 29 of ADQL-2.0) reports the unsigned_integer x to be an optional argument (the seed) to the random mathematical function. The definition of mod(x, y) in ADQL-2.0 should be amended to "Returns the remainder of x/y". Here follows what emerged as possible erratum content from those discussions.Ĭonsidering what current TAP-1.0 services using ADQL implement and the usual SQL definition of the modulo operator: Subsequently a different thread highlighted other mismatches between Table 1 (Mathematical functions) descriptions and the ADQL-2.0 grammar. Discussion went on also on this other thread.
#R round date up to nearest integer mod#
IVOA DAL mailing list thread on July 2016 highlighted a possible issue with the description of the MOD function. ADQL-2.0 Erratum 2: Mathematical Functions' Table issues
0 kommentar(er)
