Re: MSSQL compatibility layer - Mailing list pgsql-general

From Thomas Kellerer
Subject Re: MSSQL compatibility layer
Date
Msg-id 8b9d8d13-cac3-5554-3499-46c4958d9d1c@gmx.net
Whole thread Raw
In response to MSSQL compatibility layer  (James Harper <james@meadowcourt.org>)
List pgsql-general
James Harper schrieb am 02.01.2018 um 12:24:
> Right now the code is pretty rough. I've only implemented bits and
> pieces to a proof of concept stage so it's definitely way off being
> useful. At the moment the following pieces are in place:
> 
> . BackgroundWorker listening on port 1433 (hardcoded - I haven't implemented any of the udp/1434 discovery stuff)
> . Parser to take TDS from an MSSQL client and make sense of it, and then take postgres results and send back to the
client
> . Parser to take T-SQL statements and convert them to postgresql
> . Postgres data types for MSSQL types (the main ones at least) using an internal storage format compatible with TDS
> 
> It's also not really a way for an MSSQL client to access an existing
> postgres database, it's more about implementing an MSSQL-like
> database using postgres as the backend, so an application will think
> it is actually talking to an MSSQL server. I mostly don't use
> postgres types, just my own tds/tsql compatible types. I haven't
> explored what sort of performance impact this might have.
> 
> I'm not really sure if anyone else would find this interesting, but
> the code is just sitting around on my server doing nothing at the
> moment. Let me know if you want to know more and I can send you a
> copy of the code (under GPL or whatever license). I'm not subscribed
> to the list so cc me or email me direct.

Maybe that could be integrated into pgTSQL?

https://www.openscg.com/bigsql/docs/pgtsql/








pgsql-general by date:

Previous
From: Durumdara
Date:
Subject: Re: Select for update / deadlock possibility?
Next
From: Jeff Janes
Date:
Subject: Re: Select for update / deadlock possibility?