News for hackers. Stuff that matters.
Re:Babelfish: SQL Server-to-Postgres Translation Layer by etaioinshrdlu on Tuesday December 01, 2020 @01:48PM (#25268388)
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.

Re:Babelfish: SQL Server-to-Postgres Translation Layer by lukaseder on Tuesday December 01, 2020 @05:49PM (#25271093)
Re:Babelfish: SQL Server-to-Postgres Translation Layer by victor106 on Tuesday December 01, 2020 @06:22PM (#25271394)
This is so awesome. Wish I found it earlier. Thanks for posting
Re:Babelfish: SQL Server-to-Postgres Translation Layer by lukaseder on Wednesday December 02, 2020 @06:26AM (#25275423)
Well, what were you looking for? We might need to improve our SEO...
Re:Babelfish: SQL Server-to-Postgres Translation Layer by pletnes on Tuesday December 01, 2020 @02:18PM (#25268728)
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.
Re:Babelfish: SQL Server-to-Postgres Translation Layer by bbatha on Tuesday December 01, 2020 @11:29PM (#25273272)
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).
Re:Babelfish: SQL Server-to-Postgres Translation Layer by jcriddle4 on Wednesday December 02, 2020 @08:52PM (#25284306)
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.
Re:Babelfish: SQL Server-to-Postgres Translation Layer by etaioinshrdlu on Tuesday December 01, 2020 @02:52PM (#25269094)
I agree, but there might be a creative way to do it that increases customer happiness and still is a decent business.
Re:Babelfish: SQL Server-to-Postgres Translation Layer by ksec on Wednesday December 02, 2020 @12:44AM (#25273598)
>don’t see how they can benefit from such a project

I thought there were bad blood between Oracle and Amazon?

Re:Babelfish: SQL Server-to-Postgres Translation Layer by jen20 on Thursday December 03, 2020 @01:32PM (#25292597)
In that case you'd expect to see it for Oracle proper instead of MySQL first, no?
Re:Babelfish: SQL Server-to-Postgres Translation Layer by rj0049 on Thursday December 03, 2020 @10:05PM (#25298444)
The Oracle wire protocol contains a (copyrighted) haiku, so no one can reverse-engineer the Oracle wire protocol without infringing on Oracle's copyright.
Re:Babelfish: SQL Server-to-Postgres Translation Layer by linsomniac on Tuesday December 01, 2020 @02:59PM (#25269173)
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?
Re:Babelfish: SQL Server-to-Postgres Translation Layer by Conlectus on Tuesday December 01, 2020 @04:27PM (#25270154)
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.

Re:Babelfish: SQL Server-to-Postgres Translation Layer by donatj on Wednesday December 02, 2020 @12:10AM (#25273460)
> 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.

Re:Babelfish: SQL Server-to-Postgres Translation Layer by johannes1234321 on Tuesday December 01, 2020 @06:44PM (#25271575)
MySQL improved a lot in those places.
Re:Babelfish: SQL Server-to-Postgres Translation Layer by gavinray on Tuesday December 01, 2020 @07:20PM (#25271836)
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#

Re:Babelfish: SQL Server-to-Postgres Translation Layer by acmecorps on Tuesday December 01, 2020 @07:35PM (#25271961)
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!
Re:Babelfish: SQL Server-to-Postgres Translation Layer by robocat on Tuesday December 01, 2020 @02:48PM (#25269057)
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.

Re:Babelfish: SQL Server-to-Postgres Translation Layer by etaioinshrdlu on Tuesday December 01, 2020 @03:00PM (#25269187)
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...
Re:Babelfish: SQL Server-to-Postgres Translation Layer by lutoma on Tuesday December 01, 2020 @05:28PM (#25270880)
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.

Re:Babelfish: SQL Server-to-Postgres Translation Layer by brian_herman on Tuesday December 01, 2020 @08:03PM (#25272129)
Re:Babelfish: SQL Server-to-Postgres Translation Layer by touisteur on Tuesday December 01, 2020 @04:47PM (#25270405)
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.

Re:Babelfish: SQL Server-to-Postgres Translation Layer by ziftface on Tuesday December 01, 2020 @01:56PM (#25268481)
Something like this would solve a lot of my problems
Re:Babelfish: SQL Server-to-Postgres Translation Layer by leesalminen on Tuesday December 01, 2020 @02:26PM (#25268805)
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.
Re:Babelfish: SQL Server-to-Postgres Translation Layer by The_rationalist on Tuesday December 01, 2020 @03:53PM (#25269765)
Why not migrate to MariaDB? It's better than MySQL and has easy and great clustering contrary to Postgres