In MySQL, never use “utf8”. Use “utf8mb4”(medium.com) |
In MySQL, never use “utf8”. Use “utf8mb4”(medium.com) |
It is chock full of bugs and footguns that you can work around and mitigate if you know how to configure it correctly, but most of those improvements are still not the default.
And the `utf8` encoding, that does not fully support UTF-8 looks like it’ll stay around forever. ಠ_ಠ
As the author of the post says, much better to just use PostgreSQL, will save you a lot of headaches down the road.
No, it looks like the exact opposite. As the MySQL documentation clearly states:
> The utf8mb3 character set is deprecated and will be removed in a future MySQL release. Please use utf8mb4 instead. Although utf8 is currently an alias for utf8mb3, at some point utf8 will become a reference to utf8mb4. To avoid ambiguity about the meaning of utf8, consider specifying utf8mb4 explicitly for character set references instead of utf8.
I agree with you on PostgreSQL. I think the whole reason most don't use it is because their provider doesn't support/install it by default or the "legacy" system was designed with MySQL because it was already installed.
But for someone who was on MySQL 5.4-5.6 and "learned SQL" on that system - you become comfortable with things that just don't fly in SQL standard:
- Aggregate operations allowed without group by
- Group bys allowed regardless of selected columns / order by
- Case insensitive by default
... those are just a few we've had to deal with. It's on us of course. But when you build your entire legacy app on crap SQL that MySQL taught you - then MySQL 5.7 - 8 becomes irrelevant - you can't upgrade to it without disabling strict mode, or totally refactoring your code etc.
additional context (which the OP didn't reference):
https://mysqlserverteam.com/mysql-8-0-when-to-use-utf8mb3-ov...
https://mysqlserverteam.com/sushi-beer-an-introduction-of-ut...
https://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8...
hint: "Exactly the same set of characters is available in utf8mb3 and ucs2."
Until the next release, when "utf8" is updated to be a synonym for "utf8mb4", yes, use "utf8mb4" directly. At the next release, you can use "utf8" again.
This seems like an unfair characterization. You're blaming MySQL for "teaching you" nonstandard practices just because it allowed you to use them, but where did you actually learn these practices originally?
Although strict mode only became the default 4 years ago, it's been available as an option for over 15 years, and is mentioned in numerous places in the MySQL manual -- including a dedicated page on the strict-mode implications on GROUP BY and aggregation.
Anyway, I don't see how the need to rewrite some poorly-written legacy queries makes modern versions of MySQL "irrelevant". Seems ironic given the topic of GP complaining about MySQL's extreme commitment to backwards compatibility. If you don't like MySQL for personal historical reasons, that's fine, but this hardly seems like a solid argument for discouraging others from using it.
I learned SQL within MySQL 5.4-5.6, strict mode was never enabled by default (on any install of mysql i've ever done for 5.4-5.6), so hopefully one can see how that sets someone up who is learning on the fly for long term failure (you are literally free of many constraints that exist in every other db engine).
I didn't learn how to write strict SQL from the ISO guide, I learned based on what mysql would "let me do" in order to produce the desired result. So indeed that is where I went wrong.