This is fantastic news.<p>I already blogged about it when it was announced on December last year [0]. Adding SQL Server compatibility opens Postgres to new users, use cases, markets. It makes one of the most general-purpose databases to reach even more "purposes".<p>I hope work and discussions to integrate this upstream will start soon and will be fruitful. It won't be easy, but I believe it would be definitely worth the effort.<p>[0]: <a href="https://www.ongres.com/blog/aws_announces_open_source_postgres_with_sql_server_compatibility/" rel="nofollow">https://www.ongres.com/blog/aws_announces_open_source_postgr...</a>
Well this is a big deal for me: my father has run his business off a sprawling MS Access application which I've struggled at various times to try and move to something more modern with no success.<p>I wonder if this will work for connecting to MS Access directly.
It's interesting, I wouldn't have guessed the SQL dialect differences to be the main reason to pick one database over another.<p>Other comments on this suggest it's very important to them, which is a surprise to me.<p>Rather, I would have bet on either the performance characteristics for your particular situation, the knowledge of your programmers (or db admins) / recruitment pool, or perhaps integrations with other software.<p>Still, a very useful looking tool, don't want to knock it.
This may help PG take serious market share from MSSQL.<p>Also: I wonder if the shiny GUI tools that exist for MSSQL will then work from PG, and ... to what extend these tools will work with regular PG tables.<p>I really like DBeaver[1] (what I use myself), but I've seen stuff done by MSSQL DBAs using expensive GUI tools that have amazed me.<p>[1]: <a href="https://dbeaver.io/" rel="nofollow">https://dbeaver.io/</a>
And for the client side there is FreeTDS:<p><a href="https://www.freetds.org/" rel="nofollow">https://www.freetds.org/</a>
as a user of TSQL in a MSFT/Azure shop, I feel increasingly isolated from other dialects. Virtually all other databases these days use a dialect that's closer to PostGres. Does TSQL have a future? If you don't have legacy dbs and you have a choice of dbs, would TSQL ever make sense to use today?
TLDR: this is about some kind of adapter layer ("Babelfish") that lets you serve Microsoft SQL Server clients from a PostgreSQL backend, sort of like how Samba serves Microsoft SMB clients from a Linux file system. It has nothing to do with natural language translation. Oh well.
It must be compiled from the provided source code
if you want to run it.<p>The instruction for doing so is far from simple if you
do not have a dev. background.<p>I look forward to using it.
T-Sql is still the dialect I know best.
I don't see any enterprise customer using this. MS SQL server is relatively cheap. Now if this thing can work for Oracle or IBM DB2 , then may be it will be worth the risk.