ADQL Erratum 2

[Marco Molinaro]

Dear all,
this part of the erratum 2 was simply meant to align what BNF says
to what the description in the table says.
It was my understanding that, independently of the errors in the BNF
grammar, the BNF should have been trusted in this case, when
saying that x is an optional argument to rand, but leaving
unspecified what the backend actually does with that seed.

Now, I understand that different backends act differently, and that
the usage of the seed value itself is quite confused/confusing,
but if we go too far, we may slip out of the context for an erratum.

So, if we accept only the "optional" addition to the description, we
may or not harm users but we actually explicit an erratum (and
ADQL is currently under revision, so we can bring the remaining
clarification in the new revision).

If we think that adding that "optional" is useless as an erratum, we
can simply remove that part of the erratum.

Personally I would vote for the first, but it's only my opinion.

Cheers,
    Marco

2017-05-29 19:11 GMT+02:00 Walter Landry <wlandry at caltech.edu>:
> Grégory Mantelet <gmantele at ari.uni-heidelberg.de> wrote:
>>> (2) Wouldn't it be preferable if we said, in the erratum, as the new
>>> text:
>>>
>>>    rand([x]) -- Returns a random value between 0.0 and 1.0.  The
>>>    argument was initially intended to provide a random seed, if given.
>>>    It turned out, however, that in concept and implementation, it is
>>>    hard to attach stable semantics to this notion.  Hence, while an
>>>    argument is accepted for backward compatibility, clients should
>>>    expect that the 1-argument function behaves exactly like the
>>>    0-argument one.
>>>
>>> Or something like this?
>>
>>
>> I completely agree to make the seed parameter optional.
>>
>> But since this seed parameter is optionally accepted by some DBMS used
>> on some existing TAP implementation, I am not entirely convinced that
>> we should disable the possibility to use a seed parameter. Then, I
>> don't have a strong opinion about the random generation and the need
>> of "regenerating" the random numbers with a seed in a database usage.
>
> My take is that if it is not implementable for all backends, it should
> not be in the standard.  Silently changing rand(x) into rand() is just
> adding a boobytrap for users.  So I would not even make it optional.
> If you want to offer it to your users, that would be an extension.
>
> Cheers,
> Walter Landry
>
>
>