Thomas G. Lockhart wrote:
>
> > Imho, queries must return
> > consistent set of data: if I want to get rows inserted 5 days
> > ago and run query with WHERE insert_date = now() - 5 near 12PM
> > then I risk to get inconsistent set of rows if now() will be
> > evaluated for EACH tuple.
>
> 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.
yes, this is bad example -:)
>
> What should be behavior of
>
> update x set i = random();
>
> be? I would have assumed that random() is evaluated once; are there any
I don't know. I mostly concern about WHERE just because of this
defines data set to be returned by query.
> truely volatile functions in SQL92?
This is what I also would like to know.
>
> > > Also, perhaps instead of doing constant folding in the parser,
> > > consider making it part of rewrite. This pass would just traverse
> > > the tree looking for functions with constant arguements and would
> > > pre-evaluate them and and save the result in the wherever the
> > > cacheable results would be stored. No special case required except
> > > that the optimizer would have to notice that a pre-computed result
> > > was available to use as a key value.
> > This is bad for performance.
>
> What makes this bad for performance? An extra traversal of the parse
^^^^^^^^^^^^^^^
This. I don't see any reasons for this.
> tree? Or something else??
Vadim