Maximilian Roos

(no strong view on this end. Unless anyone has a strong view, I would tend to delegate to the DB's implementation until we have one...)

As discussed on dev call, the tentative proposal is: - Implement `round` as "bankers rounding" - Possibly implement `round_ties_up` / `rounds_upward` - Don't add any of the others

That sounds great @varunu28 We'd want to write functions such as https://github.com/PRQL/prql/blob/7c510444ce8fdbe4a53b6102095276f9ecfb3c1d/prqlc/prqlc/src/sql/std.sql.prql#L330-L335 for dialects that don't do bankers' rounding by default, and confirm tests such as https://github.com/PRQL/prql/blob/3dcace736ca74d4e273b65026434411bb22b2cc1/prqlc/prqlc/tests/integration/queries/arithmetic.prql#L28 work with this....

Yes, I think we could have something like a feature flag, a bit like rust's nightly features. This would also let us add experimental features, such as `loop` in its...

> In other words, the fact that Redshift does not adopt `DISTINCT ON` has nothing to do with the stability of prql-compiler functionality. Yes good point, I agree it's quite...

I don't have a strong objection... ...but in my experience it often seems most attractive to templatize things when they're changing a lot, which they typically are at the beginning....

Good question, thanks for asking. To directly answer — I would say the module docs don't really exist at the moment, and that's partly intentional. While I'm v excited about...

> * Am I correct that modules will address my use case of including common functions from a separate file? Yes! > * I don't see how that example (linked...

Yeah, that documentation is not helpful for that goal at the moment, sorry if that wasn't clearer. Let's keep this open and we can come back to it when modules...

Yes! To some extent this involves us getting more comfortable with its design. I think that currently we could definitely add some more docs even if the design might change...