Re: Storage engine or 'query engine'?krowApril 2 2007, 20:55:42 UTC
If it was completed, it would be a "storage engine" not an execution engine. See my post about this being an April's Fool Joke, and Patrick's ODBC engine if you want an execution engine.
Since this is still work in progress, I'll avoid the flame war here, but what about transaction support and everything that makes it worthwhile, IMHO at least, to go for PostgreSQL rather than MySQL? Are these planned to make it in the engine? Thanks, Alex
First of all I only made enough of this work so that I could have some fun on April 1 :)
At the moment this fits into the general definition of "if Brian takes and interest or gets a patch it will do X". From a few piece of email I've gotten their are enough users who want to do easy migrations or do federation (aka take advantage of other MySQL engines) that there is a need for this.
If most of the basics where done, hooking up transaction support would not be that difficult (in fact this is one of a couple of places where the design matches MySQL's well).
Comments 9
Or will it just act as a 'storage engine' converting to/from PGSQL data files?
Reply
Reply
Are these planned to make it in the engine?
Thanks,
Alex
Reply
At the moment this fits into the general definition of "if Brian takes and interest or gets a patch it will do X". From a few piece of email I've gotten their are enough users who want to do easy migrations or do federation (aka take advantage of other MySQL engines) that there is a need for this.
If most of the basics where done, hooking up transaction support would not be that difficult (in fact this is one of a couple of places where the design matches MySQL's well).
Reply
Reply
Reply
Reply
Reply
Reply
Leave a comment