Live data from Hacker News

Babelfish: SQL Server-to-Postgres Translation Layer

aws.amazon.com

31–40 of 118 posts

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

#31
post #8
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…

Interesting. Now where's the Oracle-to-Postgres Translation project? ;-)

isn't that what enterprisedb is selling ?

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

#32
post #19

Earlier quoted context omitted.

Their legal team might still be preparing for this one given Oracle's reputation.

SCOTUS hasn't yet ruled on Google LLC v. Oracle America Inc. One imagines that if Oracle prevails in some demonstrative manner they may very well believe their flavor of SQL is a software interface protected by copywrite. So will all the other 'software interface' owners of the world.

Apparently everyone keeps forgetting about ISO.

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

#33
post #32
post #19

Earlier quoted context omitted.

SCOTUS hasn't yet ruled on Google LLC v. Oracle America Inc. One imagines that if Oracle prevails in some demonstrative manner they may very well believe their flavor of SQL is a software interface protected by copywrite. So will all the other 'software interface' owners of the world.

Apparently everyone keeps forgetting about ISO.

That's because everyone knows about the delta between ISO and real implementations.

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

#34

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.

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

#35
post #18
post #12

Why not do this for Oracle? I've not found SQL Server to be too bad from the crazy Oracle stuff (light experience only - maybe bigger players have it worse?).

Oracle has peculiarities that you won't see in most other databases, which may make this a bit harder -- including such things as an oddball set of date/time types ("date" includes time to seconds), and treating zero length strings as SQL nulls -- '' is null evaluates to true in Oracle. It also has features like "fast refresh" on materialized views which might be tricky to emulate on other db engines. Nothing's impos…

>> '' is null

This was a major pain for us especially in our java data-access layer.

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

#36
post #33
post #32

Earlier quoted context omitted.

Apparently everyone keeps forgetting about ISO.

That's because everyone knows about the delta between ISO and real implementations.

Yet they still forget about pay to play with ISO standards.

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

#37
post #26

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.

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.

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

#39
post #30

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?

Don't discount the cost, which is borderline astronomical; if you're on Enterprise, you're paying tens of thousands a year. For large installation, potentially six figures. And that's on-prem which is the cheapest way to do it more often than not.

A 2-core Enterprise license is nearly $14,000.

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

#40
post #28
post #5

I hope this means I can finally connect postgres to excel with the same ease I can connect SQL server.

What does “connect” mean in this context? Read data from SQL server into an excel spreadsheet?

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.
Post reply on HN