Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but
От | Mischa Sandberg |
---|---|
Тема | Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but |
Дата | |
Msg-id | 44723468.6050202@ca.sophos.com обсуждение исходный текст |
Ответ на | Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?) ("Jim C. Nasby" <jnasby@pervasive.com>) |
Список | pgsql-hackers |
Jim C. Nasby wrote: > On Sun, May 21, 2006 at 02:58:17PM -0700, Josh Berkus wrote: >> Actually, porting TSQL to PL/pgSQL would be very hard. I speak as an expert >> TSQL developer. For example, most data manipulation in TSQL is done through >> updatable cursors, something we don't currently support. There are plenty of direct runtime incompatibilities, that have to be implemented not as language-to-language, but language-to-procedure. That also makes them stick out as the first thing to refactor and reimplement, once the basic working system has been ported :-) Hadn't thought about updatable cursors, but solved that problem before in SimbaExpress and SimbaFusion with (effectively) arrays of OID's. That's what I love about PG: so many rich consistent facilities that you can implement things that tie other DB's in knots. >> Also, T-SQL uses >> un-ordered, callable parameters for SPs, something which we *also* don't >> support. Not such a big. Any translation has full access to the catalog (ported over to the target PG system) and the parser/translator can fill in the blanks. > And TSQL doesn't fail a transaction on an error, resulting in code like > > UPDATE ... > > if @@error = 0 then > UPDATE ... > end > if @@error = 0 then > ... Yeah, transaction error behaviour always brings out the nasty incompatibilities (Jim, was that a major problem on Project Lance?). -- Engineers think that equations approximate reality. Physicists think that reality approximates the equations. Mathematicians never make the connection.
В списке pgsql-hackers по дате отправления: