-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Group By with Coalesce #83
Comments
myQuery = select (sum_ #a `as` #sum :* #c) (from (subquery sub) & groupBy #c)
where
sub = select (#a :* (#a + #b) `as` #c) (from (table #t)) `as` #sub As for generalizing grouping elements to arbitrary expressions in Squeal, it would look like replacing |
Yes, I realized along the way that the escape hatch for GroupBy was not really an option. I think I'll add another subquery like you recommand (that's a pity because what I'm working on is already complex enough without adding all that !), unless I find another way of expressing the same problem in SQL. I wouldn't necessarily be in favour of grouping for all arbitrary expressions. But the COALESCE case might be worth it, for it might be a common solution when you want to do a UNION-like query, but for whatever reason it doesn't fit your needs so you resort to a |
I'm noticing a theme ;-) |
Hahaha ! I've been working on the two biggest queries of my codebase recently. If I can write them using Squeal, it will be my pleasure to announce we use Squeal in production ! |
How many schemum objects does your code have? And merry Christmas! |
We've currently 16 tables and 4 typedefs. (Merry Christmas and happy holidays to you too !) |
According to the documentation of PG on GROUP BY:
However, the current version of Squeal is limited to columns, not "an arbitrary expression formed from input-column values". Though I suppose these would be fairy rare, and hard to fit inside the type system, I have one case which should not be that rare: a GROUP BY using a COALESCE over two fields (context: a FULL OUTER JOIN with two similar columns). I'm gonna try to find a way to shortcut this through an UnsafeGrouping expression, but it could be worth it (in the long term, obviously) to investigate ways to model more complex GROUP BY expressions.
The text was updated successfully, but these errors were encountered: