ADQL Erratum 2

[Markus Demleitner]

Dear DAL,

There's currently ADQL Erraturm 2,
http://wiki.ivoa.net/twiki/bin/view/IVOA/ADQL-2_0-Err-2 under
discussion.

While I believe the main content is essentially uncontentious (I
personally would prefer square brackets around optional arguments),
I'm not so sure about:

  rand(x)
  Returns a random value between 0.0 and 1.0, *where x is an 
  optional seed value*.

Frankly, I believe we need to say a bit more about this if we expect
it to work.

I *think* what the authors intended here was:

  "If an argument to RAND is given, a single call to a setseed-like
  function should be performed in the transaction that will later be
  used to execute the query itself."

It certainly makes no sense to set the seed as part of the query
itself (you'd then get *very* unrandom numbers indeed).

Full disclosure: DaCHS currently does neither: random(n) is
translated to the same query as random().  My rationale is that I
doubt you'll get any sort of reproducability (which setseed is about)
either way, given that it's not clear if the PRNG is per-transaction
or might be pushed along by queries executed in parallel (Postgres
docs aren't clear here) and that, with set calculus and the query
planner in the background, you can't really expect a particular
sequence of rows and hence a particular sequence of random numbers by
rows.

Of course, it's also a pain to implement that extra query one would
need for halfway reasonable behaviour.

So:

(1) Does anyone actually implement random(int) (rather than just
falling back to random())?  And if so, what do you do?

(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?

          -- Markus