> This is perhaps a bad example, because now() (and 'now') return the
> transaction time, guaranteed to be the same for each row evaluation of a
> query, and the same for every query within a transaction.
>
> What should be behavior of
>
> update x set i = random();
>
> be? I would have assumed that random() is evaluated once; are there any
> truely volatile functions in SQL92?
Hmmm, I would have thought that was a clever way to get a nice random
value into each row ;-)
But seriously, we have the iscacheable attribute for functions. So,
update pg_func set iscacheable = 'false' where pg_func.name = 'random';
and you get different random values in all the rows. Or do
update pg_func set iscacheable = 'true' where pg_func.name = 'random';
and you get the same random value in all the rows.
Or at least this is how postgres was intended to work. It was meant to
be an extensible table driven system. Hardcoding stuff "because it is the
right way" is really assuming that we know better than the users what they
want to do. Almost never true.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- If simplicity worked, the world would be overrun with insects. -
