returnString edited a comment on pull request #288: URL: https://github.com/apache/arrow-datafusion/pull/288#issuecomment-840800353
> I also am not sure I would call now() "stateful" in the sense that it has state that changes during the execution of the query. It is more like "parameterized" or something with a parameter that is filled in prior to execution Yeah, in Postgres parlance this kind of function is "stable" (read: consistent over the course of a single txn given the same inputs) as opposed to "immutable" (which can't reference _anything_ outside its args/constants) - still not the best breakdown imo, but a little bit closer maybe. Cache invalidation and naming things, right? 😅 > Also, I am not convinced about how valuable a general purpose StatefulFunction will be (though of course it depends on a proposal that is not yet written ;) ) Off the top of my head I think it'll open up some potential for generalised optimisation passes over function usage in queries according to function class, i.e. the optimiser rule used for the initial implementation of this PR but applicable to arbitrary functions provided they indicate themselves to be "stable". > is it fair to say that there is some urgency in the NOW? In this case, I agree that the closure is a great stop-gap and we should go for it. Personally I think so, it's a pretty generally useful function and opens up lots of good time-series use cases as @alamb mentioned. Edit: also, I'm happy to assist in defining this proposed future work or even drive it outright; not just trying to generate tasks for other people ;) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
