Maximilian Roos

> Just to add this: the two `artist_id` columns are not exactly the same - because of your left join, the output may contain albums whose artists were not found....

Yes, very much agree @eitsupi . Do you have thoughts on what a good design would be? Would you want to default to `INNER JOIN`? To `USING`? Because while I...

I'm aligned with @eitsupi's perspective... Let me give a quick summary of my logic for `USING` and then some problems with relying on it: ### Case for `USING` / equi-joins...

I realize we've discussed this a lot, so I don't mean to keep pestering here. But I have really liked using `USING` when I write SQL — I even design...

> ```sql > SELECT a.*, b.* FROM a JOIN b USING (some_id) -- both a.some_id and b.some_id are returned > ``` Yes, I definitely empathize that it makes the column...

Interesting! You're correct that PRQL is designed for the query use-case, though because that's where we perceive the greatest need. How do you tradeoff having these constraints at the DB...

@armanm I very much agree with your thoughts! I think they're very perceptive. Joining you for a moment in zooming out: - PRQL could be Coffeescript — a cool idea...

> If the compiler can expose the following information, this will open the door for many possibilities that shouldn't be baked into PRQL now or maybe never: > > *...

I actually didn't realize we had come so far on this, that's very impressive. Maybe I add some docs on this? I also think we could add things like the...

OK. I'm happy to help document & solidify it if someone starts consuming it. So I think we're at a decent place: - Observability of the query is useful, both...