> Maybe you can give some examples of administration that require you to?
That require you to what? Nothing in MySQL inherently requires sudo or involves "hooking into sudo".
The mysql server daemon (mysqld) typically runs as mysql:mysql, with directories owned by mysql:mysql in the Unix permission model, but this is all entirely dependent on how you have installed it.
Inside the database server, you can freely configure database users, which are entirely separate from the notion of OS users. Although the default superuser in MySQL is typically called "root", it can be called anything, and is not tied to the OS root user.
Connecting to MySQL can be done either via tcp/ip or locally through a Unix domain socket; this is all completely configurable on a per-database-user level inside the database itself.
When connecting over the local Unix domain socket, connections are permitted if the requested user name has a database user entry with @localhost for the host portion.
I suppose your OS user is relevant in two ways when using the local Unix domain socket:
* You need OS permissions to interact with the socket. That's the case with any Unix domain socket, not MySQL specific.
* If you're using the standard `mysql` command-line client and you haven't supplied a database user name for the connection, your OS user name will be used as a default.
So perhaps you were running `sudo mysql ...` to connect to the local mysqld because your OS user lacked the :mysql group to interact with the socket; or because your OS user did not have a corresponding database user/grants inside the database. In the latter case, you can just type `mysql -u root ...` instead to specify what database user to connect as. There's literally nothing requiring sudo in that case.
That said, you can optionally make this passwordless using the auth_socket auth plugin, in which case there are extra considerations around having the users match and maybe that's what happened to you. But there's no requirement to use that passwordless auth_socket approach for administration.
> Collations and charsets and the DB engine and other stuff wasn't particularly good either,
That's quite vague and it sounds like you aren't well-informed about MySQL in general so I suppose there's little sense in diving into it.
> I don't think it matters. 8 is what, a decade old or so?
MySQL 8.0 came out less than seven years ago, but that's irrelevant since everything I described above regarding permissions is equally true in MySQL 8.0.
Correct, my assertion is that MySQL administration does NOT require use of sudo or su at all in any way. I was responding to your claim about MySQL administration “hooking into sudo rather than a dedicated databaser user” which is just wrong as described above.
To re-summarize, MySQL administration involves use of a mysql user (meaning, a user defined inside the database server and NOT an OS user), and since there is no 1:1 mapping between OS and db users in MySQL there is quite obviously no requirement to use sudo or su for anything at all.
Postgres is not relevant to that claim, as we’re discussing MySQL behavior here.
Furthermore none of this behavior is specific to MySQL 5 (it hasn't changed in 8.0, nor anything after it like 8.4 or 9.0) and none of it relates to defaults.
It's entirely possible some default changed in the package for your chosen Linux distribution / package management system, but that is outside of MySQL itself.
No, this is about comparison between Postgres and MySQL.
When you administrate Postgres you typically run psql as another user, with MySQL you typically don't, instead you tend to use the root@localhost in the database or sudo on the rather large set of binaries that gets installed with the server.
And I don't really care whether you think the old MyISAM engine was fine and not problematic or whether you've come across problems with utf8mb3 or latin1 or whatever, and I especially don't care whether you think I'm an experienced, professional MySQL user or not.
I’ve already explained repeatedly that use of sudo is completely unnecessary with MySQL. As for the rest, that’s gibberish - for example I certainly don’t think MyISAM is fine for anything, and have absolutely never said anything pro-MyISAM in all the years I’ve been on HN. As for utf8mb3, I literally make widely-used schema management software that flags any use of utf8mb3 as a problem by default.
I have no idea why you keep replying with non sequiturs, but I’m going to stop responding now, as you don’t seem to understand anything I am saying.
That require you to what? Nothing in MySQL inherently requires sudo or involves "hooking into sudo".
The mysql server daemon (mysqld) typically runs as mysql:mysql, with directories owned by mysql:mysql in the Unix permission model, but this is all entirely dependent on how you have installed it.
Inside the database server, you can freely configure database users, which are entirely separate from the notion of OS users. Although the default superuser in MySQL is typically called "root", it can be called anything, and is not tied to the OS root user.
Connecting to MySQL can be done either via tcp/ip or locally through a Unix domain socket; this is all completely configurable on a per-database-user level inside the database itself.
When connecting over the local Unix domain socket, connections are permitted if the requested user name has a database user entry with @localhost for the host portion.
I suppose your OS user is relevant in two ways when using the local Unix domain socket:
* You need OS permissions to interact with the socket. That's the case with any Unix domain socket, not MySQL specific.
* If you're using the standard `mysql` command-line client and you haven't supplied a database user name for the connection, your OS user name will be used as a default.
So perhaps you were running `sudo mysql ...` to connect to the local mysqld because your OS user lacked the :mysql group to interact with the socket; or because your OS user did not have a corresponding database user/grants inside the database. In the latter case, you can just type `mysql -u root ...` instead to specify what database user to connect as. There's literally nothing requiring sudo in that case.
That said, you can optionally make this passwordless using the auth_socket auth plugin, in which case there are extra considerations around having the users match and maybe that's what happened to you. But there's no requirement to use that passwordless auth_socket approach for administration.
> Collations and charsets and the DB engine and other stuff wasn't particularly good either,
That's quite vague and it sounds like you aren't well-informed about MySQL in general so I suppose there's little sense in diving into it.
> I don't think it matters. 8 is what, a decade old or so?
MySQL 8.0 came out less than seven years ago, but that's irrelevant since everything I described above regarding permissions is equally true in MySQL 8.0.