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

...

> Network Time Protocol

But how often are you going to have to resync with NTP in order
to keep synchronised to the resolution required by Firebird to
create truly duplicate timestampls? Even dual CPU machine have
their problems keeping in tight timing sync.

But that is really beside the point...

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

I believe you are making assumptions here that cannot be held
true on a broad basis. People have their reasons for using
UUID, just have they may have their reasons for installing UDFs
that prepare other data not easily or reliably held identical
across mulitple isolated computers. (eg: reading information
from some local configuration source - that must therefore also
be kept in total synchronisation, but with no obvious way to
ensure that this is done.)

It does not really matter whether it is timestamp, UUID or some
other specific application requirement. By requiring that two
isolated instances of the server produce identical data from an
identical series of client API calls you will be limiting the
generality of the clustering solution - for some applications
it will not be feasible.

Timestamp is the interesting one because it is the most common,
if it cannot be solved then it means that very few applications
would fit the requirements of the proposed solution. To ensure
that the clustering solution worked you would have to test your
hardware first, and reject any unable to keep time in sync to
(at least) millisecond resolution between NTP synchronisations.
But even if you solve this one, you have still not solved the
more general problem and so the "solution" remains limited.


That all sounds more critical that I really mean to be. It is
an interesting proposal, I am just doubtful that it can be made
to work in enough situations to encourage building support for
it into the main source.

--
Geoff Worboys
Telesis Computing