=?UTF-8?Q?Torsten_F=C3=B6rtsch?= <tfoertsch123@xxxxxxxxx> writes:
> I know that. My question was about the execution order of f1 and f2 in
> "SELECT f1(), f2()". In theory they can be executed in any order. But since
> the side effect in nextval determines the result of currval, I am asking if
> that order is well-defined or considered an implementation detail like in C.
The current implementation evaluates select-list items left to right.
I doubt we'd be eager to change that, since there are surely many
applications that depend on that behavior, whether it's formally specified
or not. But elsewhere in a query than the select target list, there are
no guarantees, and there's lots of precedent for whacking around the
evaluation order in e.g. WHERE.
I'd be a little more wary with examples like your other one:
SELECT * FROM (VALUES (nextval('s'), currval('s'))) t;
since there's an additional unspecified question there, which is
whether the planner will "flatten" the sub-select. To put it more
clearly, you'd be taking big risks with
SELECT y, x FROM (VALUES (nextval('s'), currval('s'))) t(x, y);
Right now it seems the nextval is done first, but I would not want to bet
on that staying true in the future. [ experiments some more ... ]
Actually, looks like we have a rule against flattening sub-selects whose
targetlists contain volatile functions, so maybe you'd get away with that
for the indefinite future too.
regards, tom lane
