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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
