Karl Gutwin

I think it's related to the reference to `source` here: https://github.com/PRQL/prql/blob/e6650494ceb50c1838cc8a291d2d9d31661dd9f1/prqlc/prqlc/src/semantic/std.prql#L70-L73 At least, when I tried changing `source` there to `sourceby`, and recompiled, the test case doesn't raise the error;...

(I know this issue is old...) What database engine were you using? Assuming this was in the playground, [DuckDB's docs](https://duckdb.org/docs/stable/sql/query_syntax/setops.html) on `UNION` specify that: > Traditional set operations unify queries...

I did some experimentation with this example. The `from codes \n into S` section isn't necessary to reproduce the problem, this produces the same output: ```elm from data join side:left...

I think this may actually be by design. I recently read through the discussion in #1363 and this comment suggests that using `group`, even if it is empty, will reset...

I wanted to try to bisect this, but I can't reproduce a successful compile of your PRQL query going back to version 0.9.0. SQL output from 0.9.0: ```sql WITH RECURSIVE...

> `derive a = 2` will add a new field and because name `a` already exists in the tuple, it will remove that name, but not the whole field. What...

I'm not sure that more use of unnamed fields is going to be easy for users to follow - it puts more weight on the structure of the query rather...

The trouble about removing relation aliases in `join` (and possibly also an issue with `from`) is that it makes doing things like self joins much harder. Extending your previous example...

What about just passing the column as an argument to the function? This seems to work fine for me... ``` let take_smallest = func n c tbl -> ( from...

Here's an interesting behavior (I was experimenting a bit with some of your examples): ```elm from t select {b, d=b} ``` produces: ```sql SELECT b, b AS d FROM t...