Den 2011-04-05 10:12 skrev Paul Vinkenoog såhär:

> That very surprising. timestamp '<string>' is supposed to be just
> shorthand syntax for cast('<string>' as timestamp), so if the result
> differs, that's rather alarming.
>
> I just ran the following query a number of times:
>
> select timestamp 'now', cast ('now' as timestamp) from rdb$database
>
> About one time in ten, the values differ (the second value being a
> little higher).
>
> If I swap the columns:
>
> select cast ('now' as timestamp), timestamp 'now' from rdb$database
>
> it's still the CAST (now in the first column) that's sometimes higher.
>
> I'd definitely call this a bug, but maybe someone can explain why it
> "should be" this way?

If it had always been the rightmost expression that was higher I'd say
it was caused by "non constness" and evaluation order.

I tried this query:

select cast ('now' as timestamp),
timestamp 'now',
cast ('now' as timestamp),
timestamp 'now',
cast ('now' as timestamp),
timestamp 'now',
cast ('now' as timestamp),
timestamp 'now',
cast ('now' as timestamp),
timestamp 'now',
cast ('now' as timestamp),
timestamp 'now'
from rdb$database

It results in two values differing a few ms, alternating from column to
tolumn, e.g. (one column per row):
2011-04-05 10:30:27.561
2011-04-05 10:30:27.560
2011-04-05 10:30:27.561
2011-04-05 10:30:27.560
2011-04-05 10:30:27.561
2011-04-05 10:30:27.560
2011-04-05 10:30:27.561
2011-04-05 10:30:27.560
2011-04-05 10:30:27.561
2011-04-05 10:30:27.560
2011-04-05 10:30:27.561
2011-04-05 10:30:27.560

But I guess that could be explained by query optimizer recognizing
common expressions and evaluating each of the two expressions once only.

Remains to explain why it's always the cast that's higher, regardless of
column order...?

Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64