Geoff Worboys wrote:

>> - As you know, the 'random' numbers aren't (in a usually
>> implementation) really random. The random number generator
>> must be initialized with a 'seed'
>>
>
> Yes this is true. But you do need to acknowledge that this
> failing is considered a bug in most situations. Writing code
> to assume a bug will continue to behave consistently is not
> a good idea.
>
>

If we want to have a 'true' random numbers generator then perhaps is
better to implement it on the client side. For my POV I hardly see a
need for a true randomly RAND() SQL function. (If you want to use a
random gen for cryptographic purposes, so far so good, this can be done
internally). IMHO, the need for a HA cluster is much higher than for
doing random number programming on the server side in SQL.

>> - If you talking about "now" as a variable which gets the
>> current time, this isn't a problem in a LAN,
>>
>
> Down to 10000ths of the second? Even 1000ths of a second?
> I suggest it could well be a problem even on a LAN, it is
> certainly a problem in a more generic situation.
>
>
>

Yes. From Wikipedia:

<citation>

Network Time Protocol

The Network Time Protocol (NTP) is a protocol for synchronizing the
clocks of computer systems over packet-switched, variable-latency data
networks. NTP uses UDP port 123 as its transport layer. It is designed
particularly to resist the effects of variable latency.

NTP is one of the oldest Internet protocols still in use (since before
1985). NTP was originally designed by Dave Mills of the University of
Delaware, who still maintains it, along with a team of volunteers.

Overview

NTP uses Marzullo's algorithm with the UTC time scale, including support
for features such as leap seconds. NTPv4 can usually maintain time to
within 10 milliseconds (1/100 s) over the public Internet, and can
achieve accuracies of 200 MICROseconds (1/5000 s) or better in local
area networks under ideal conditions.

</citation>

As you see, on LAN is 5 times better. IMHO, it's enough. I don't ever
think that I can put the cluster nodes on a WAN. The problems which
arise (latencies, multiple routes aso.) are so big, that is almost
impossible to build a cluster there. Clients on WAN/Internet connecting
to a cluster located on a LAN/hi-speed net - yes. Cluster nodes on
WAN/Internet - no. My MHO...

> Whatever the actual situation with the above there are other
> attributes guaranteed to give different results - for example
> UUID/GUID calculations (usually based on MAC address). These
> issues need to be resolved before your suggestion could be
> considered viable.
>
>

Why should one implement SQL functions for calculating these things when
we have generators? It is really needed?

hth,

m. th.