Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan

At 01:25 PM 8/20/00 -0400, Tom Lane wrote:

>However, even if we had a concept of "constant within a transaction/
>scan/whatever", currval() would not qualify --- what if there is a
>nextval() being invoked somewhere else in the query, possibly inside a
>user-defined function where the optimizer has no chance of seeing it?
>
>In short, there is no way of optimizing currval() in the way you want
>without risking breakage.

Does Postgres guarantee order of execution of functions? Many languages
don't other than to follow precedence rules, which is why functions with
side-effects (such as nextval) can yield "implementation defined" or
whatever results.

My point is that such queries may not yield predictable results. Perhaps
today due to left-right execution order or the like, but do you want to
guarantee a defined order of execution in the future?

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.