Tom Lane wrote:
>
> Tiago Antão <tra@fct.unl.pt> writes:
> > Isn't the problem more general than just nextval?
>
> Yes it is, and that's why I'm not very excited about the idea of
> adding special-case logic for nextval/currval into the optimizer.
>
> It's fairly easy to get around this problem in plpgsql,
it is, once you know that psql implements volatile currval ;)
> eg
>
> declare x int;
> begin
> x := currval('seq');
> return f1 from foo where seqfld = x;
>
> so I really am going to resist suggestions that the optimizer should
> make invalid assumptions about currval by itself ...
Why is assuming a constant currval any more "invalid" than not doing so ?
As the execution order of functions is undefined, can't we safely state that
all
currval's are evaluated first, before any other functions that could change
its return value ?
currval is not like random which changes its value without any external
reason.
Afaik, assuming it to return a constant within a single query is at least as
correct as not doing so, only more predictable.
----------------
Hannu
