this post was submitted on 27 Dec 2023
544 points (96.7% liked)
Programmer Humor
19623 readers
2 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well, if you lose the OOPism of those dots, we can talk.
Anyway, I'm really against the "having" tag. You need another keyword so that you can apply your filter after the group by?
That's a good point, I didn't even think about it, maybe a more functional style would make more sense?
Boy then are you going to hate
QUALIFYYes, I do. It's a lot of effort and hidden functionality to try to paper over the fact that the statements do not compose.
having is less annoying way of not doing needless/bug-prone repetition. if you
select someCalculatedValue(someInput) as lolyou can addhaving lol > 42in mysql, whereas without (ie in pgsql) you’d need to dowhere someCalculatedValue(someInput) > 42, and make sure changes to that call stay in sync despite how far apart they are in a complex sql statement.Postgres has the
havingclause. If it didn't, that wouldn't work, as you can't use aggregates in awhere. If you have to make do withouthaving, for some reason, you can use a subquery, something likeselect * from (select someCalculatedValue(someInput) as lol) as stuff where lol > 42, which is very verbose, but doesn't cause the sync problem.Also, I don't think they were saying the capability
havinggives is bad, but that a new query language should be designed such that you get that capability without it.