Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
having is less annoying way of not doing needless/bug-prone repetition. if you selectsomeCalculatedValue(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.
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 (selectsomeCalculatedValue(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.
having is less annoying way of not doing needless/bug-prone repetition. if you
select someCalculatedValue(someInput) as lol
you can addhaving lol > 42
in 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
having
clause. 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
having
gives is bad, but that a new query language should be designed such that you get that capability without it.