Maximilian Roos

> The problem here is that DBT emits result of `{{ }}` as an SQL identifier, which is not the same as PRQL identifier. Yes, well summarized > The ideal...

I think we can do these with standard `INTERSECT` operators — along with https://github.com/prql/prql/issues/656? Or are these not well-supported? e.g. Postgres https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-intersect/

Thanks @spenserblack — you're correct that SQL Server doesn't support `USING`. So we should convert that to your 3rd option; `ON employees.employee_id = jobs.employee_id`. One issue may be that the...

This would be a moderate difficulty issue for someone who wanted to start contributing. I & others would be around to show where to start / answer any questions.

I'm definitely open to this. As we continue iterating on the language, we wouldn't want this to block changes. But if there were a willing contributor, we could create one...

@chris-pikul that looks very pressive, thanks for writing it up. I'm open to adding this to our docs. I think for the moment the canonical source should be the actual...

> But a question opens: would we want `f"{date:%y-%m}"` or `f"{date:YYYY-MM}"`? Or something else? I'm not a great fan of the `%`, but it does seem to be more standard....

> That's what I intended `DialectHandler` for. But I didn't think we would need to move functions such as `translate_func_call` into there. Do you think that's necessary? We can keep...

Here's an example failure: https://github.com/prql/prql/runs/6030035804?check_suite_focus=true

This is a diagnosis in https://github.com/prql/prql/pull/358. It's driven by https://github.com/raphlinus/pulldown-cmark/issues/507. We're skipping this on Windows for the moment. I won't be the best person to fix, since I don't have...