5 ms·

> 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 err

by platz 5y ago

> 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".

smarx007 5y ago
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.
- DaiPlusPlus 5y ago
  If you’re using EF then just use the correct ADO.NET library and use native features - why use Babelfish with EF?
  - moron4hire 5y ago
    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.
    - DaiPlusPlus 5y ago
      > 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!)
- justsomeuser 5y ago
  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.

by platz 5y ago

smarx007 5y ago

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.

DaiPlusPlus 5y ago
If you’re using EF then just use the correct ADO.NET library and use native features - why use Babelfish with EF?
- moron4hire 5y ago
  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.
  - DaiPlusPlus 5y ago
    > 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!)
justsomeuser 5y ago
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.