The Future of MySQL is PostgreSQL: an extension for the MySQL wire protocol | Hacker News Reader

The Future of MySQL is PostgreSQL: an extension for the MySQL wire protocol

hachyderm.io

35 pointspabs310 comments

What is the latest with MariaDB?

Seems like it gets ignored by "MySQL" when, originally, it was a dropin replacement since MySQL was Oracle owned.

I honestly find MySql much simpler to use, create replication architectures, fix problems and use in general.

And its not like you switch to Postgres and your indexes are 10x faster.

Postgres does seems to be marginally faster in some edge cases, but with it you have to learn a whole host of weird slash commands, the tooling just isn’t that great, and setup is unbelievably complicated compared to MySql and heavily heavily intertwined with the host os.

The real advantage Postgres had is some cool party tricks (like pivot functions, super handy for prepping data for Ml) but those being non ansi means you are flirting with disaster if they ever change or go away. Backups on MySql are also not a great affair… xtrabackup is marginally ok but requires some intense scripting. (Honestly I question the usefulness of backups anyway, I think slow replicas are probably the was to go).

It’s certainly not bad, but it’s also not like it isn’t without a myriad of rough spots.

"SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax near '' at line 21."

when line 21 is 175 characters long. also, the fact that anything other than InnoDB is barely real ACID. also, the stuck development and lack of support for json, uuid and many other things.

mysql being user-friendly (and especially beginner-friendly) is a massive hoax.

This should instead be something like this:

    SQL Error (1064):
      20 |
      21 |  ...ROM my_table JOIN other_table ON GROUP BY
      22 |                                      ^^^^^

This should not be hard. Both MySQL and Postgres do have the span of the parsing error and they do have the original query somewhere.

Zero code changes? No matter how complex and MySQL specific the logic is?

Well there are other Pg extensions that port MySQL specific functions and PL/PSM. One may even be able to leverage rules to rewrite certain syntax differences like intervals. (I saw such a project for an effort to partially support TSQL.)

Probably something like an "80% of applications can be supported with 20% of the MySQL-specialized flavor", which is probably closer to 90/10, and those 90% of applications account for 99.9% of MySQL installations.

This is probably referring to "zero changes to your driver code" and not "zero changes to the SQL you send over this driver".

Translating between SQL dialects is notoriously hard and attempts to translate [1] are working in 95% of cases. But the last 5% would require 5x amount of work. That's because "SQL dialect" also includes weird edge cases of type inference of things like COALESCE(5, FALSE) and emulation of system catalogs (pg_catalog, information_schema).

[1] https://github.com/tobymao/sqlglot

I agree with the skepticism behind your question. I’ve used both at different firms heavily over the years. I’ll believe it when I see it. What about MySQL’s local @ variables… is that supported in Postgres? I guess they do say they will support MySQL’s procedural language… is there a difference between that and MySQL stored procedure compatibility?

Reply on news.ycombinator.com