Braden Shepherdson

I'll pick this up again next week. For now I want to note for posterity that there's actually two things going wrong in the bad SQL: 1. The `expression name...

However, this is related to field refs and so will be affected by steps taken to fix #36185. Refs are currently subject to a kind of "late binding capture" like...

At least the initial stage of this, adding the linter and `:clj-kondo/ignore`-ing all the existing violations, is straightforward.

This is even worse on master now :scream: The query seems to be just broken with the second-stage filter. The network request looks sound, returning the count and discount columns...

This reproduces on 0.49.0 RC1 as well. These issues share a repro but the symptoms are different, so I've filed a separate issue #38861 for that. Until that "covering" issue...

My #38861 is a dupe of #10493 , which is a FE issue under active work. I'm actually working on the underlying issue anyway, since it should be solved by...

Yes, that's all the aggregations. I think individually these changes are good, but I think we should take advantage of multimethod dispatch to reduce duplication here, like is done elsewhere...

This is still happening, at least with Postgres. Here's the error message I got: ``` ERROR: operator does not exist: timestamp without time zone >= character varying Hint: No operator...

From @luizarakaki: - this is closer to a feature request than a bug - the best place to be filtering the query is _the earliest stage with an aggregation_ in...

The difference in these queries is that the post-aggregation `negative` expression adds a second stage. So this example illustrates what Arakaki said (and I repeated [here](https://github.com/metabase/metabase/issues/19744#issuecomment-1949020580)): that the best default...