Don Baccus wrote:
>
> At 02:18 PM 8/20/00 -0400, Tom Lane wrote:
>
> >However, that just shows that some patterns of usage of the function
> >will yield unpredictable results. I don't think that translates to an
> >argument that the optimizer is allowed to make semantics-altering
> >transformations...
>
> Very much depends on the language spec, if such usage is "implementation
> defined" you can do pretty much whatever you want. Agressive optimizers
> in traditional compilers take advantage of this.
>
> In the case given, though, there's no particular reason why an application
> can't grab "currval()" and then use the value returned in the subsequent
> query.
>
> On the other hand, heuristics like "if there's no nextval() in the
> query, then currval() can be treated as a constant" are very common in
> the traditional compiler world, too ...
And it seems to me that even if there are both nextval and curval we can
crab "curval()" and use the value returned.
It will fail if we have no preceeding nextval inside the session, but so
will
any other plan that tries to evaluate currval before nextval.
So I don't see that we would be violating the spec more by marking
currval as const than by not doing so.
And we do get faster queries, even for the weird queres with undefined
behaviour ;)
---------------
Hannu