Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?)
От | Jim C. Nasby |
---|---|
Тема | Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?) |
Дата | |
Msg-id | 20060522150020.GK64371@pervasive.com обсуждение исходный текст |
Ответ на | Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?) (Mischa Sandberg <mischa@ca.sophos.com>) |
Ответы |
Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?)
|
Список | pgsql-hackers |
On Fri, May 19, 2006 at 01:03:08PM -0700, Mischa Sandberg wrote: > >On Thursday 18 May 2006 12:38, Josh Berkus wrote: > >>Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's > >>make *migration* easier for those who wake up and smell the BS, but > >>migration can (and probably should) be one-way. > > Somebody earlier was mentioning, why no automatic transformer from > Transact-SQL > to PLPGSQL (maybe with a bunch of glue routines). The grammar is not a > problem, > though you have to wonder at all the wired-in keywords (T-SQL always felt > like COBOL). > > The stumbling blocks are not in language, but function. Many of those > functions are rarely used, but some big ones are quite common ... > > T-SQL has statement-level triggers, and they get used a lot (some big apps > ONLY put code in triggers). Statement-level triggers are very efficient for > maintaining aggregates; the closest PG has are rewrite rules. Yeah, I wish PostgreSQL had them. I've got clients that could certainly make use of them. > For high-end MSSQL shops, a high value is being able to trace and profile > (EXPLAIN) every client SQL command from the server side ... with plenty of > options for selective trace. This would also be highly valuable to have in PostgreSQL. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: