-
Notifications
You must be signed in to change notification settings - Fork 115
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
consistent naming in aggregate functions #63 #65
base: master
Are you sure you want to change the base?
Conversation
We need to be careful about the types |
I fear this will require another typeclass. |
I added constraints for all the currently publicly implemented aggregations, hopefully that should fill any type hole that is currently there. I'm not sure if the naming is best, it also could be in another module? |
Need to get rid of |
Yes. Removed. |
This looks like the right idea. Let me give it some more thought. |
Coming back to this, it is good work but I am concerned about the proliferation of type classes. I will leave it as an open PR for further discussion. |
I just ran into this, trying to average an integer column. What is your thinking on this now? |
Hi @hesselink, can you clarify what you mean? You used |
I'm running |
I see. The workaround (which you probably already know) is to use I don't know whether the best solution is to use a typeclass like @coubeatczech's implementation or to provide several differently-named functions. I don't really like proliferating the number of typeclasses but perhaps it's neater overall. What do you think? |
I think a type class with a functional dependency like @coubeatczech created, or the equivalent type family, is the neatest solution and maps very cleanly to the way postgres treats the output types of functions: they depend on the input types. But I know you are worried about complicating the types. I'm not sure how differently named functions would work here, though. You'd need a different aggregator for each input type, right? |
Yes, I was thinking of something clunky like |
That's indeed a bit clunky. Like I said I prefer the classes (also over type families I think, since it matches nicely with contraints like One advantage of class + FD is that it can also be used for operators, whereas creating different versions there will get really ugly: you'll either get ascii soup, or you have to stop using operators for the less common types. |
Another advantage: it's mostly backwards compatible, in that people who are using the operations at correct types already aren't going to have to change their code. With the different specializations, they'll have to look at the code to see at what types they're using them, and change the names accordingly. |
OK, since @coubeatczech already implemented this and chose typeclasses we can go for that. It needs rebasing though, which either I will do when I get round to it or you can do and send me a new PR. |
Also, at least in
9.3.6
, theStdP
etc. is not referring to any aggregate function. I don't know if was a alias, which is removed now or it's just broken or else.