On 2017-04-11 17:25:52 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Tom, do you have any opinion on the volatility stuff? > > What was the previous behavior for such cases? If it was reasonably > sane, we probably have to preserve it. If it was unpredictable or > completely wacko, maybe we don't.
Previously we'd stash the result in a new tuplestore, because it happened inside ExecMakeTableFunctionResult()'s fallback path. The inner tuplestore (from the proper SRF) would get evaluated via the the isDone mechanism. That'd imo be a fair amount of work to emulate, because we'd have to manually go over the tuplesttore. But given that we do *not* have similar semantics for volatiles in the targetlist, I'm quite unconvinced that that's necessary. Consider e.g. my previous example of SELECT * FROM CAST(srf() * volatile_func() AS whatnot) rewritten into a saner version as SELECT srf * volatile_func() FROM srf() AS srf; here volatile_func() would before and now get re-evaluated if there's a rewind, and would only be invoked if the row is actually evaluated. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
