Re: functions with side effect

Torsten Förtsch <tfoertsch123@gmail.com> 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.