Chris Swenson

Not sure about `measure`/`calculation` vs `aggregate`/`analytic`...

Yeah, currently all `except` does is delete `state` from the fields, which doesn't work if you have a filter using that field... `except` came from a time when we didn't...

Renaming `except` to `private` is an interesting idea, but we do have the same issue with `accept`: ```malloy source: a1 is airports extend { where: state='CA' } extend { accept:...

It should be possible now, using the `sql_functions` experiment, to do something like `sql_date("LAST_DAY(${created_at_day}, WEEK)")`, which currently requires that `created_at_day` be a predefined field. Probably some day we'll support something...

Related: though this issue is probably easier to fix than mine https://github.com/malloydata/malloy/issues/1482

I think this SQL works: Though this is probably less performant... ```sql SELECT copy_0."n" as "n" FROM ( SELECT base."generate_series" as n FROM generate_series(1, 10) as base ) as nums_with_copy...

I think the fix might be: - make sure to check the `on` statement for joins, and generate those joins - if a join is "two levels deep" or more...

Currently `cast(x as type)` is unsafe cast and `x::type` is safe cast, so it would be a breaking change to make `x::type` unsafe cast. That said, I so kinda like...

I think this needs a @lloydtabb look to see if he thinks it's correct. I think it's correct now?

In your matrix, can we clarify `path` with `source_path` and `field_path`? That is, I'm not sure with the current matrix how `some_join.avg(some_field)` behaves in comparison to`some_join.some_field.avg()`. Also, it seems like...