Hacker News new | ask | show | jobs
by etaioinshrdlu 2032 days ago
Don't hate me for it, but I'd like this for MySQL to postgres too. At least as a stepping stone.

Use case: some of my SQL syntax depends on MySQL but I realize I made a poor life choice and would rather have transactional DDL and a myriad of better features on postgres.

10 comments

This is so awesome. Wish I found it earlier. Thanks for posting
Well, what were you looking for? We might need to improve our SEO...
For SQL server, AWS can save their customers money by cutting license cost (to MS). MySQL is already free so I don’t see how they can benefit from such a project.
They can go one better — they can fork the parsers out of both projects and run it against a common query planner/storage engine (aurora).
If you have several thousand stored procs and triggers then having to not rewrite all of that is actually likely over a million in savings.
I agree, but there might be a creative way to do it that increases customer happiness and still is a decent business.
>don’t see how they can benefit from such a project

I thought there were bad blood between Oracle and Amazon?

In that case you'd expect to see it for Oracle proper instead of MySQL first, no?
The Oracle wire protocol contains a (copyrighted) haiku, so no one can reverse-engineer the Oracle wire protocol without infringing on Oracle's copyright.
You might be able to get away with staying with MySQL or a variant. Years ago I did an "interview problem" to generate a report of some accounting data of a sample data set in MySQL. The details are foggy now, but I ended up doing it all using advanced SQL features that I thought only existed in PostgreSQL (you know, or Oracle), but whatever engine I ended up using had it as well. It was probably the latest Percona or Maria?
MySQL has worse guarantees in several cases, though. For example, using `SERIALIZABLE` isolation means your queries can deadlock when run in parallel.

Likewise, selecting a column not present in a GROUP BY leads to random values being returned.

> Likewise, selecting a column not present in a GROUP BY leads to random values being returned.

That hasn't been the default behavior for something like 5 years.

Beyond that the values aren't "random" as much as "one of the values from the set" which can be a useful feature in cares where you want any of the values and don't want the performance hit that comes with using an aggregate function particularly on very very large sets.

MySQL improved a lot in those places.
pgloader does this (and much much more) in a single command:

https://github.com/dimitri/pgloader

  pgloader \
    mysql://user:password@mysql:3306/database \
    postgresql://postgres:root@localhost:5432/postgres
This is a gem of a tool. Surprised nobody has mentioned it. Supports SQLite and MS-SQL too.

https://pgloader.readthedocs.io/en/latest/ref/mysql.html#

Absolutely, absolute love pgloader! So painless and quite straightforward. Saved me lots of time migrating my production db. Highly, highly recommend if anyone wants to migrate from MySQL to PG!
However if the translation layer is designed for consistency, like Babelfish, it would have to replicate many of the MySQL “faults” too... e.g. it would need to have the same non-transactional DDL so it acted “correctly”!

And it would need to replicate the specialised data types like utf8mb3.

To use PostgreSQL features (such as JSON datatype) would presumably need a separate data connection and transaction, because if it isn’t implemented by MySQL, then the syntax wouldn’t be supported by Babelfish.

You would get some wins, but you don’t get a blend of the best of both.

It would be nice if it could aim for doing the sane thing over exact MySQL compatibility. But I agree it would be a minefield...
I would love that. There is so much mediocre but popular software out there that uses hard-coded MySQL queries instead of some abstraction layer.

Having to use MySQL/MariaDB after usually dealing with PostgreSQL always feels like such a downgrade.

Can't you do it with a foreign data wrapper or the equivalent in mysql? Maybe keep your mysql-specific queries as views in mysql and call them from pg?

Just spitballing, sorry, I love FDWs.

Something like this would solve a lot of my problems
I’d considered migrating MySQL to Postgres on a 200 table production app more than once. Couldn’t find any good tooling at the time so I just sucked it up and lived with my life choices.
Why not migrate to MariaDB? It's better than MySQL and has easy and great clustering contrary to Postgres