mysql emulation layer for postgres
Is there any project to build a mysql emulation layer for postgres? All my searches come up with the April1 post from a few years ago. Would anyone else find such a thing useful? I have a few servers where I'm running mysql only because the application I am using demands it (wordpress, mainly). Thanks James
James Harper <james@ejbdigital.com.au> writes:
Is there any project to build a mysql emulation layer for postgres? All my searches come up with the April1 post from a few years ago.
Would anyone else find such a thing useful? I have a few servers where I'm running mysql only because the application I am using demands it (wordpress, mainly).
For something simple like Wordpress, it's probably not hard to just patch wordpress to make it work, but in the general case, there's a lot of odd coner case behaviour in MySQL that likely makes it hard to do. -- Stewart Smith
James Harper <james@ejbdigital.com.au> writes:
Is there any project to build a mysql emulation layer for postgres? All my searches come up with the April1 post from a few years ago.
Would anyone else find such a thing useful? I have a few servers where I'm running mysql only because the application I am using demands it (wordpress, mainly).
For something simple like Wordpress, it's probably not hard to just patch wordpress to make it work, but in the general case, there's a lot of odd coner case behaviour in MySQL that likely makes it hard to do.
What sort of behaviour? I wrote a plugin for postgres a while back that would allow you to point an MSSQL application at it (eg it listened on port 1433 and pretended to be MSSQL). It worked for some basic stuff but got too complicated and I never got around to refactoring it. In particular matching up the various locking and isolation levels was never going to be perfect, so it would only work for pretty basic applications. James
James Harper <james@ejbdigital.com.au> writes:
James Harper <james@ejbdigital.com.au> writes:
Is there any project to build a mysql emulation layer for postgres? All my searches come up with the April1 post from a few years ago.
Would anyone else find such a thing useful? I have a few servers where I'm running mysql only because the application I am using demands it (wordpress, mainly).
For something simple like Wordpress, it's probably not hard to just patch wordpress to make it work, but in the general case, there's a lot of odd coner case behaviour in MySQL that likely makes it hard to do.
What sort of behaviour?
I wrote a plugin for postgres a while back that would allow you to point an MSSQL application at it (eg it listened on port 1433 and pretended to be MSSQL). It worked for some basic stuff but got too complicated and I never got around to refactoring it. In particular matching up the various locking and isolation levels was never going to be perfect, so it would only work for pretty basic applications.
https://dev.mysql.com/doc/refman/5.0/en/sql-mode.html and https://dev.mysql.com/doc/refman/5.0/en/differences-from-ansi.html are good places to start. There's some behaviour that is probably safe to ignore. I'd look at things around data types though, there's some corner cases with dates, times, IIRC DECIMAL/float things that may/may not translate well, and apps may/may not care about. -- Stewart Smith
James Harper <james@ejbdigital.com.au> writes:
James Harper <james@ejbdigital.com.au> writes:
Is there any project to build a mysql emulation layer for postgres? All my searches come up with the April1 post from a few years ago.
Would anyone else find such a thing useful? I have a few servers where I'm running mysql only because the application I am using demands it (wordpress, mainly).
For something simple like Wordpress, it's probably not hard to just patch wordpress to make it work, but in the general case, there's a lot of odd coner case behaviour in MySQL that likely makes it hard to do.
What sort of behaviour?
I wrote a plugin for postgres a while back that would allow you to point an MSSQL application at it (eg it listened on port 1433 and pretended to be MSSQL). It worked for some basic stuff but got too complicated and I never got around to refactoring it. In particular matching up the various locking and isolation levels was never going to be perfect, so it would only work for pretty basic applications.
https://dev.mysql.com/doc/refman/5.0/en/sql-mode.html and https://dev.mysql.com/doc/refman/5.0/en/differences-from-ansi.html are good places to start.
There's some behaviour that is probably safe to ignore. I'd look at things around data types though, there's some corner cases with dates, times, IIRC DECIMAL/float things that may/may not translate well, and apps may/may not care about.
Postgres is highly extensible. I wrote compatible types for my mssql emulator to avoid exactly that problem (being Microsoft, they have their own ideas of how types should behave, and also I could make the underlying data format compatible with the wire format). I'd be doing a complete parse and rewrite of the language though, so any of the language and type differences would be easily solvable. Some of the other differences your links highlight around foreign key and atomicity behaviour would be harder. Thanks James
James Harper <james@ejbdigital.com.au> writes:
Postgres is highly extensible. I wrote compatible types for my mssql emulator to avoid exactly that problem (being Microsoft, they have their own ideas of how types should behave, and also I could make the underlying data format compatible with the wire format).
I'd be doing a complete parse and rewrite of the language though, so any of the language and type differences would be easily solvable. Some of the other differences your links highlight around foreign key and atomicity behaviour would be harder.
On the plus side, a lot of apps don't care that much if at all :) OTOH, it may not be worth the effort if it's just one simple app... but that doesn't mean it wouldn't be a *lot* of fun and a good challenge to try and do it :) -- Stewart Smith
James Harper <james@ejbdigital.com.au> writes:
There's some behaviour that is probably safe to ignore. I'd look at things around data types though, there's some corner cases with dates, times, IIRC DECIMAL/float things that may/may not translate well, and apps may/may not care about.
Postgres is highly extensible. I wrote compatible types for my mssql emulator to avoid exactly that problem (being Microsoft, they have their own ideas of how types should behave, and also I could make the underlying data format compatible with the wire format).
I'd be doing a complete parse and rewrite of the language though, so any of the language and type differences would be easily solvable. Some of the other differences your links highlight around foreign key and atomicity behaviour would be harder.
Actually, reading this week's LWN reminded me that PostgreSQL (up until the just-went-alpha 9.5) had no equivalent to the MySQL INSERT .... ON DUPLICATE KEY UPDATE syntax - what's known as UPSERT in postgresql circles. -- Stewart Smith
Postgres is highly extensible. I wrote compatible types for my mssql emulator to avoid exactly that problem (being Microsoft, they have their own ideas of how types should behave, and also I could make the underlying data format compatible with the wire format).
I'd be doing a complete parse and rewrite of the language though, so any of the language and type differences would be easily solvable. Some of the other differences your links highlight around foreign key and atomicity behaviour would be harder.
Actually, reading this week's LWN reminded me that PostgreSQL (up until the just-went-alpha 9.5) had no equivalent to the MySQL INSERT .... ON DUPLICATE KEY UPDATE syntax - what's known as UPSERT in postgresql circles.
Yeah I seem to remember MSSQL having a similar thing that I had to fake. James
participants (2)
-
James Harper -
Stewart Smith