Hacker News Reader

Comment by platz | Hacker News Reader

> we do not expect to support all functionalities right away. Instead, we focused on the most common T-SQL commands and returning the correct response or an error message

Well that sounds like it will be fun to wake up to. Do i have to worry about every windowing function to behave the same way or will there be "approximations".

View on HN

As I read it, "correct response or an error message" does not include "approximations". Your app either runs on it or fails with an error. I assume many apps use quite a limited set of T-SQL features when going through Entity Framework, for example, and that's the market AWS is after.

I think the issue is that you cannot test 100% of your SQL queries the way you can with a compiled language.

What if there is an “if” branch taken 1 in 1000 times? You would not encounter the error during development.

If you’re using EF then just use the correct ADO.NET library and use native features - why use Babelfish with EF?

Well, in particular, the NPGSQL EF driver is pretty buggy. We frequently exhaust our connection pool and we don't even have a large database. Given the design of EF, it's difficult to see how we could possibly do anything different that would avoid exhaustion. It's a pretty vanilla setup.

> Given the design of EF

There's nothing about the design of EF that relates to how connections work: you can let the DbContext manage connections for you or can provide your own. (I assume you know that a DbContext is meant to be short-lived with a single owner) - so I'm very hesitant to say the issue is with EF's design or that the design of EF means you can't mitigate any issues with the PostgreSQL library for .NET.

Do you have a StackOverflow or GitHub post for this? I'd like to know more about this precisely because I'm thinking of switching from Azure SQL to Postgres for its superior data-modelling features (deferred constraints!)

Reply on news.ycombinator.com