this post was submitted on 27 Dec 2023
546 points (96.7% liked)

Programmer Humor

19522 readers
238 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

founded 1 year ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
546
no.. just no (lemmy.ca)
submitted 10 months ago by reimufumo@lemmy.ca to c/programmer_humor@programming.dev
92 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] marcos@lemmy.world 3 points 10 months ago (3 children)

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?

[–] QuazarOmega@lemy.lol 2 points 10 months ago

Well, if you lose the OOPism of those dots, we can talk.

That's a good point, I didn't even think about it, maybe a more functional style would make more sense?

[–] physicswizard@lemmy.ml 1 points 10 months ago (1 children)

Boy then are you going to hate QUALIFY

[–] marcos@lemmy.world 2 points 10 months ago

Yes, I do. It's a lot of effort and hidden functionality to try to paper over the fact that the statements do not compose.

[–] rubythulhu@lemmy.blahaj.zone 0 points 10 months ago (1 children)

having is less annoying way of not doing needless/bug-prone repetition. if you select someCalculatedValue(someInput) as lol you can add having lol > 42 in mysql, whereas without (ie in pgsql) you’d need to do where someCalculatedValue(someInput) > 42, and make sure changes to that call stay in sync despite how far apart they are in a complex sql statement.

[–] docAvid@midwest.social 1 points 10 months ago

Postgres has the having clause. If it didn't, that wouldn't work, as you can't use aggregates in a where. If you have to make do without having, for some reason, you can use a subquery, something like select * 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 having gives is bad, but that a new query language should be designed such that you get that capability without it.