Marko Klopets

Non-ideal but we used to have a similar issue and we worked around it by just always running a regex replacement to remove these spaces automatically straight after compilation to...

The main problem we're seeing with s-strings (even more so than e.g. variable resolution) is that you lose database-agnostic-ness (which is something we're trying our best to maintain).

a couple of thoughts: - I quite like using [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) for commit messages in any case - there's something called [Release Please](https://github.com/googleapis/release-please) for automation on top of conventional commits...

>I think it would be OK to have the same version across all crates I think that in an ideal world, we'd be able to [semantically version](https://semver.org/) all packages, which...

`\` also seems like a decent solution to me

I don't think this error that's thrown in this case (on the final line of the PRQL) is related to joining at all – it's that any columns other than...

Although I don't personally like the idea of default filtering implicitly being AND-ed together (I prefer explicit things), it's slightly weird that `select`, `filter` and `derive` all function differently when...

> My concern is that derive only adds _columns_ not _rows_. FWIW, derive & select can already add rows when doing stuff such as `s"json_array_elements()"`

> > > My concern is that derive only adds _columns_ not _rows_. > > > > > > FWIW, derive & select can already add rows when doing stuff...

@Georift a PR would be greatly appreciated indeed. Sorry about the silence, everybody.