Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1733550238.1246885335292.JavaMail.jira@brutus>
Date: Mon, 6 Jul 2009 06:02:15 -0700 (PDT)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3314) RAND(SEED INTEGER) builtin function
 always returns the same random value for a given seed.
In-Reply-To: <13445233.1199990614175.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kathey Marsden updated DERBY-3314:
----------------------------------

    Urgency: Normal

Triaged for 10.5.2. Set urgency  to Normal. I did not mark Wrong query result or Deviation from standard, because if I read the comments correctly, we just need a second RAND() function that takes no arguments, but first need the JDBC spec to allow for this.

My only concern regarding urgency on this one is that if someone needed it fixed in a hurry, we won't be able to fix it because of the spec work that is required.

> 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.1.3
>            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.