Babelfish: SQL Server-to-Postgres Translation Layer • Hacker News Board

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#51

Post by vetinari » Tue, Dec 01, 2020, 8:42 PM UTC

ComodoHacker wrote: post #50

pc86 wrote: post #40

Earlier quoted context omitted.

Not the GP but yes I've seen a lot of folks go through the Data tab in Excel and connect to a SQL database to display data directly.

Excel can connect to PostgreSQL as well.

Yes, it can on Windows, both via psqlODBC and Npgsql, when you find out which .net runtime version your Excel version uses.

On Mac, it is more interesting; there's only ODBC, Microsoft doesn't support the same psqlODBC you can use in Windows and you have to purchase one of the supported commercial ODBC drivers.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#52

Post by The_rationalist » Tue, Dec 01, 2020, 8:53 PM UTC

etaioinshrdlu wrote: post #16

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.

Why not migrate to MariaDB? It's better than MySQL and has easy and great clustering contrary to Postgres

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#53

Post by bdcravens » Tue, Dec 01, 2020, 9:08 PM UTC

jnsie wrote: post #30

bdcravens wrote: post #11

As someone who has been fighting with a SQL Server to Postgresql conversion this sounds AMAZING. Too bad it won't be available before my conversion is complete (and if it is, that's an even sadder proposition)

Out of curiosity: besides cost, are there other significant reasons that drive your desire to switch?

Plenty of reasons, but principally we want to bring our stack in line with the most common practices (ie, Rails/Postgresql) for simplicity's sake; this is crucial for our small team.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#54

Post by Tostino » Tue, Dec 01, 2020, 9:09 PM UTC

mattashii wrote: post #7

mjasay wrote: post #6

Earlier quoted context omitted.

Correct. The focus is on 100% correctness. As I wrote in the post: "Over its 35 years in existence, SQL Server has evolved to meet a wide array of use cases. When first made available on GitHub, Babelfish won’t be able to handle every use case, but will be able to tackle the most common application scenarios. Most importantly, Babelfish will meet the correctness objective. That is, if Babelfish doesn’t yet support sp…

Would you know if Babelfish will be released for RDS for PostgreSQL as well? The only mentions so far are for Aurora for PostgreSQL, or self-hosted PostgreSQL.

Very good question, seems to be a strange decision. Maybe it doesn't meet what they deem up to the standards to include it in RDS due to the nature of how the backend is hosted (just a guess). Could be something as simple as the dependencies the extension requires are incompatible with what the RDS servers run. It would be very nice if the RDS team had some guidelines on what it takes to get an extension accepted for RDS with a good framework people can follow to ensure their extension complies with the security requirements, etc. Then have a way to submit an extension to be included and have it be reviewed and given guidance on any changes needed to comply (for a fee potentially).

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#55

Post by sqlserver1 » Tue, Dec 01, 2020, 9:14 PM UTC

joshuaellinger wrote: post #46

This is great. I suspect that I have exactly the right use case for this. The two main issues with running SQL Server are (1) you have to license all the cores on a system and (2) the standard license only recognizes up to 64GB RAM. So I actually wound up buying a 3GHz single-socket system for around $10K to save $20K on the SQL license. With this, I can move a couple of the big DBs to another system that has 32 Core…

(2) is not accurate. SQL Server Standard Edition supports up to 128 GB RAM

https://docs.microsoft.com/en-us/sql/sql-server/editions-and...

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#56

Post by Svip » Tue, Dec 01, 2020, 9:18 PM UTC

JonathonW wrote: post #44

linuxhiker wrote: post #38

This is interesting because it will also help Sybase migrations. SQL Server is the "brand name" but there are still a lot of people stuck on Sybase.

Will it? MSSQL and Sybase diverged somewhere around 27 years ago; anything that Sybase and Microsoft did differently since then would likely be completely incompatible.

As someone who converted a 400'000+ LoC Sybase SQL codebase to Microsoft SQL Server about 5-6 years ago, they did diverged since around 2000, but not by a lot. We ended up with a codebase that could support both Sybase and MSSQL, where when differences occurred, we essentially used compiler directives, which wasn't that often.

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#57

Post by Conlectus » Tue, Dec 01, 2020, 9:27 PM UTC

linsomniac wrote: post #42

etaioinshrdlu wrote: post #16

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.

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 o…

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

#58

Post by touisteur » Tue, Dec 01, 2020, 9:47 PM UTC

etaioinshrdlu wrote: post #16

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.

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

#59

Post by orf » Tue, Dec 01, 2020, 10:22 PM UTC

> A commonly used datatype to store monetary values is the MONEY data type. In SQL Server, the MONEY data type’s behavior is fixed using four digits to the right of the decimal (e.g., $12.8123). However, in PostgreSQL, the MONEY data type is fixed using two digits to the right of the decimal.

> So, when the application tries to store a value of $12.8123, by example, PostgreSQL will round to $12.81. This subtle difference will result in a rounding error and break an application if not correctly addressed. To ensure correctness in Babelfish, we need to ensure such differences, small and large, are handled with absolute fidelity.

How are they going to solve this with just a query translation layer? Isn't information lost on save?

Re: Babelfish: SQL Server-to-Postgres Translation Layer

#60

Post by lutoma » Tue, Dec 01, 2020, 10:28 PM UTC

etaioinshrdlu wrote: post #16

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.

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.