Re:Function pipelines: Building functional programming into ...
by akulkarni on Tuesday October 19, 2021 @12:23PM
(#28919960)
Also, the team picked `->` as the operator, which I thought was a very natural and intuitive choice :-)
e.g.,
SELECT device_id, timevector(ts, val) -> sort() -> delta() -> abs() -> sum() as volatility
Re:Function pipelines: Building functional programming into ...
by OJFord on Tuesday October 19, 2021 @12:32PM
(#28920066)
What if those functions (were something that) returned json{,b}?
Oh or I see timevector returns a custom datatype, so I suppose the answer is it has to be one of a fixed number of provided types?
Re:Function pipelines: Building functional programming into ...
by Lockerman on Tuesday October 19, 2021 @12:45PM
(#28920229)
> Oh or I see timevector returns a custom datatype, so I suppose the answer is it has to be one of a fixed number of provided types?
Exactly! These aren't general arithmetic operators, they're specifically for mapping arithmetic operations over timevectors.
Re:Function pipelines: Building functional programming into ...
by djk447 on Tuesday October 19, 2021 @12:45PM
(#28920227)
(NB: post author here)
We're planning on providing various outputs, json is definitely one format we'd want to support, want to file a github issue with the layout that you'd want and we can start getting some feedback to implement?
Totally understand the concern, for now, it’s just for a particular datatype, all of the other operations are happening normally inside your query and you can still use window functions...
And btw, I love window functions and will probably be doing a post on them, but they can be a little bit weird and have some really odd ordering properties with aggregates etc.
The point of this is really much more about providing choices for folks. But yeah, if we find that people are just getting really confused we could re-consider, that’s part of why we released it experimentally.