The Npgsql.FSharp.Tasks can be tricky, can introduce serious bugs and confusion.

I just wanted to ask if that was possible to introduce methods with …Throwing or …OrThrow suffix, because – in my opinion – it is very common that there is nothing one can do with failed results other than give up and let the app blow.

This is my case: I have no idea what can I do with infrastructure errors like broken database connections. All I can do is to let the app crash, the system-wide infrastructure will restart it and if that happens, the operational team gets an alert, so they can figure out what is wrong with databases. There is nothing I can do within my app to solve it.

Now I can see there is a new namespace Npgsql.FSharp.Tasks which provides almost identical functions with slightly different signatures (result types are not wrapped in result anymore).

Why is it dangerous? Let’s say we have two exactly same pieces of code:

• using Npgsql.FSharp: … |> Sql.executeNonQuery |> ignore
• using Npgsql.FSharp.Tasks: … |> Sql.executeNonQuery |> ignore

So, when you look at that one line of code you cannot tell it you are ignoring ANY kind of errors (like database crashed) or if you are ignoring just the result of successful operation.

The meaning of the line of code changes dramatically based on open declaration in a different place of a file. In my opinion, it can lead to critical bugs in application, because it’s so easy to misuse the API.

[Zaid-Ajaj]

As of v4.0 there are no longer two namespaces, just Npgsql.FSharp which what Npgsql.FSharp.Tasks previously provided but now it is the default

[ericsampson]

Or split into two packages…