I think the discussion point was php was too easy and that encouraged new developers or less hardcore developers to adopt it.
Some of the defaults like globals being turned on by default led to security holes. How people were creating sql statements at the time concating strings led to sql injection issues.
There were never any bad parts . There are new features like the spread operator that are newer and not available in earlier versions. I try to stay away from them if I think the application will need to run on older versions but otherwise I feel like I can use any feature.
Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
There where, and continue to be, large numbers of bad parts. Magic methods that do random things in certain cases, terribly defined interfaces (array_search), ridiculous typing, an impossibly incoherent standard library, etc.
> Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
Where did you get that idea? Postgres can run as any user.
In fact, I recently switched my applications to use Postgres even during unit tests (instead of SQLite), i.e. that testing instance runs under my normal login user. That change actually made the CI go faster because compiling the Go SQLite driver takes much much longer (about 30-60 seconds) than spinning up a Postgres from scratch in a temp directory (about 2 seconds) and using that instead.
@fizixer: I don't use MySQL, but I've heard it's not nearly as bad as it once was. I use PostgreSQL for everything from traditional relational data to time series to job queues and am 100% satisfied. Hasn't once let me down. The only caveat is that clustering is still easier to do with MySQL than with Postgres from what I hear, so if you have really really big setups that require that, that should be considered.
> I don't use MySQL, but I've heard it's not nearly as bad as it once was.
MySQL 5.7+ is decent. Where it loses out to PostgreSQL is the lack of plugins/extensions. PostgreSQL is extensible in ways MySQL users can only dream of (e.g. timescaledb, pg_trgm)
Also, the forking of MySQL and MariaDB has resulted in 2 very similar databases that people consider interchangeable - but aren't. There's plenty of "gotchas" if SQL is meant to run on both.
Some of the defaults like globals being turned on by default led to security holes. How people were creating sql statements at the time concating strings led to sql injection issues.
There were never any bad parts . There are new features like the spread operator that are newer and not available in earlier versions. I try to stay away from them if I think the application will need to run on older versions but otherwise I feel like I can use any feature.
Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement