Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Babelfish: SQL Server-to-Postgres Translation Layer

aws.amazon.com

Post reply on HN
Print view View original

91–100 of 118 posts

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

#91

Post by Tostino »

orf wrote: post #59

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

I'd say the best solution here is if a really nice money data type was developed that is configurable as necessary to hopefully satisfy the MS SQL idiosyncrasies while also maybe supporting a bit richer superset of desirable features you'd want in a money type. You could even have things like temporal currency conversion type queries if you had the right feature set.

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

#92

Post by fellowniusmonk »

About every 3 years when I've tried to migrate and use some db migration tool it always seems to throw frustrating string/formatting errors, each time I've smacked my forehead and ended up just grabbing Ruby and ActiveRecord, it just always seems to work without any weird parsing errors.

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

#93

Post by statictype »

I tried to build a T-Sql-to-pgsql compiler to enable us to migrate our code but ran into some fundamental issues.

Sql Server allows you to have arbitrary statements/declarations embedded in your sql queries. It also doesn't require type information to be specified in many places.

How does this translator get around that?

For example, if I have this bit of unoptimized T-Sql:

   declare @m int
   select @m=[MeterID] from EnergyMeters where MeterLocation='/a/b/c';

   select sum([Value]) from EnergyData where [MeterID]=@m;
How would this get translated to pgsql? (Yes, you can combine this specific statement into a single query - this is a trivial example to highlight the point)

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

#95

Post by statictype »

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)

How are you doing your migration right now? Rewriting code by hand?

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

#96

Post by bdcravens »

statictype wrote: post #95
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)

How are you doing your migration right now? Rewriting code by hand?

We got very far using DMS (Data Migration Service) and SCT (Schema Conversion Tool), especially once we put in some smart renaming conventions. It does like to make varchars everything it doesn't type-convert automatically. We also had to explicitly rename objects, mostly indexes - it like to truncate names, often overwriting previous entries when it truncates the name. Beyond that, there's some procedures and application code to rewrite (it's a Rails app built atop an older database that didn't follow standard Rails conventions) but I'd say automation and semi-automation (ie smart find-and-replace) got us 80% of the way.

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

#98

Post by dragonwriter »

statictype wrote: post #93

I tried to build a T-Sql-to-pgsql compiler to enable us to migrate our code but ran into some fundamental issues. Sql Server allows you to have arbitrary statements/declarations embedded in your sql queries. It also doesn't require type information to be specified in many places. How does this translator get around that? For example, if I have this bit of unoptimized T-Sql: declare @m int select @m=[MeterID] from Ene…

If you are just binding variables with early (before the last one that returns data) selects like that, just turning them into subqueries or factoring them out to CTEs works, which should be reasonably straightforward mechanically.

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

#99

Post by xet7 »

topspin wrote: post #19
Grazester wrote: post #9

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.

So if Oracle wins, can AWS sue Oracle for Oracle having implemented AWS S3 API ?

https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Task...

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

#100

Post by c17r »

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…

I still remember the day that MS switch the SQL Server pricing from per-socket to per-core. Dark day, indeed.
Post reply on HN