[ 
https://issues.apache.org/jira/browse/DERBY-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558059#action_12558059
 ] 

Daniel John Debrunner commented on DERBY-3314:
----------------------------------------------

ODBC has the RAND function optionally taking a seed value, JDBC doesn't. The 
optional seed value makes sense for the next example I found where RAND(seed) 
sets the seed value for subsequent calls to RAND() [no seed] within the same 
statement. Ie. the sequence of random numbers is within a statement.

Basically these two statements would return the same set of values (three 
random numbers) since the statement starts a new random sequence and RAND(3) 
sets the seed of that sequence to be 3..

VALUES RAND(3), RAND(), RAND();
VALUES RAND(3), RAND(), RAND();

Though that does imply some ordering in expression evaluation which I didn't 
think SQL guarantees.


> RAND(SEED INTEGER) builtin function always returns the same random value for 
> a given seed.
> ------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3314
>                 URL: https://issues.apache.org/jira/browse/DERBY-3314
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>
> RAND or {fn RAND(seed)} exists to match the JDBC specification (section C.1)
>    RAND(integer) Random floating point for seed integer
> Trouble is that Derby creates a new Random() instance for every call leading 
> to the same return value for the same seed. Seems to be useful, the function 
> should return a new random number even when handed the same seed.
> Some more specification is probably needed, when does a sequence based upon a 
> seed start?
>    - first call by any connection
>    - sequence within a connection
>    - sequence within a sql context (e.g. procedure call, statement etc.)
> Also need to be wary of memory leaks if the engine needs to hold onto Random 
> objects beyond the lifetime of the RAND call.
> ij> values rand(3);
> 1
> ----------------------
> 0.731057369148862
> 1 row selected
> ij> values rand(3);
> 1
> ----------------------
> 0.731057369148862
> 1 row selected
> ij> values {fn rand(3)};
> 1
> ----------------------
> 0.731057369148862
> 1 row selected

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to