Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.
By Cvbge on
Anyone knows good automatic script/site that would take <project>.mysql and produce <project>.pgsql ?
(Of course retouches will be needed, but still)
Comments
Killes found (probably on
Killes found (probably on google ;)) this link:
http://www.omnistarinc.com/~fonin/downloads.php#my2pg
The script is quite good, has some quirks (incorrect ALTER TABLE statements, might produce incorrect PRIMARY KEY statements), but other that that looks very good.
MySQL queries can be
MySQL queries can be converted to Postgre SQL using the below tool :
http://www.swissql.com/products/sqlone-consolejava/sqlone-consolejava.html
- Shiv
SQLFairy can also convert basic DDL
sqlfairy.sourceforge.net can convert CREATE etc. to and from lots of different DBs including PostgreSQL and MySQL.
Consider the ADOdb approach
If you convert from MySQL to PostgreSQL then someone else has to convert from MySQL to Oracle and everything else. If everyone made a concerted effort to use an ADOdb style approach to database independent SQL then we could convert Drupal to work with every database.
I keep pushing ADOdb because ADOdb has moved to OO and ADOdb makes ASP to PHP conversions easier. There are at least two major products that I would like to plug into Drupal and both use ADOdb.
petermoulding.com/web_architect
petermoulding.com/web_architect
Drupal is losing ground and may go away like ArsDigita
the survey of mysql vs. Postgresql was "self-selecting", and therefore invalid, because if a person wanted a database other than mysql, they wouldn't even bother with Drupal and its simplistic programming framework and hard coded database dependencies, which is 1960's programming logic.
You would go to smoother frameworks such as bitweaver.org. Bitweaver uses adodb, as all reasonable PHP frameworks should. And postgresql with bitweaver was up and running in like 45 minutes. Reliance on mysql is fine until next year when Oracle buys MySql as it did innodb, and starts charging. Mark my words, Mysql is going to be taken out of the GPL sooner than later.
If the capabilities of gpled mysql stay the same, how can drupal itself get more sophisticated? Personally I don't think the small mysql programming staff can even duplicate the innodb stuff. It is a fatal Achilles Heel. Without major structural improvements I see Drupal going away like Arsdigita and mysql going away like Dbase 3+
What did you use in the 1960s?
Which database did you use in the 1960s?
Which programming language did you use in the 1960s?
One of my teachers hand made a magnetic recording disk in the 1950s. 5000 bit capacity.
In the 1960s you could perform random access on magnetic tape because NCR cut magnetic tape in to strips and built a machine to access the strips randomly. I worked with someone who had worked on them in the late 60s. He told me about a database system he wrote to work on the random access tape. The system sounded similar to stuff we use today.
There is a rich history of small dedicated teams producing great software. MySQL is in Europe where people want alternatives to Oracle and Microsoft. Some of those people want commercial support. There is enough to sustain MySQL even if Innodb goes away.
If Oracle kills the market for InnoDB by immediately messing with MySQL then the switch to PostgreSQL is easier than a switch to an Oracle style license. If Oracle immediately demand huge wads of cash then MySQL can jump in to developing alternatives including plugging PostgreSQL into MySQL. For Drupal the switch to PostgreSQL compatibility is relatively easy by either using ADOdb or using ADOdb style abstraction.
The real danger is if Oracle slowly starves MySQL. Once MySQL start dealing with the devil, they will be sucked dry of cash to the point where they can no longer fund an alternative to InnoDB. It is better for MySQL to walk away from InnoDB and leave Oracle with an unsaleable product.
Reverse engineering InnoDB, Oracle, and PostgreSQL style row level transactions for MySQL is easy compared to all the other code that MySQL have developed.
petermoulding.com/web_architect
petermoulding.com/web_architect
Responses
So, what are we at Drupal.org supposed to do? Put out the questionnaire on Joomla or Xaraya?
The audience was Drupal users, and this is what we got. If you wanted to say something about MySQL, that was your chance to say it.
From what I see, virtually all Open Source CMSs out there support MySQL. The reason is not technical superiority, the reason is wide spread acceptance, availability, and suitability to task.
How many ISPs have MySQL vs. PostgreSQL ... see?
I think that Oracle's motives of buying InnoBase (the company that makes InnoDB) are sinister. They want to dry out the revenue stream for MySQL AB (the company that makes MySQL).
What you forget is that once a product is GPL, existing versions remain GPL. So, both MySQL 5 and InnoDB are GPL and will stay so. If Oracle changes that for future versions of InnoDB, then MySQL (the company, not the product) will suffer.
Who says we want to be more sophisticated? The philosophy here is a small, fast, flexible core. Adding complexity is against the Drupal way of doing things.
For their revenue, that may be true. But not for the technology itself. Both MySQL and InnoDB are GPL now, and anyone can pick them up and maintain them. All it needs is a sponsoring company, and we are back in business.
Remember that it is not only Drupal who uses MySQL. It is tens of thousands of application developers, ISPs, ...etc. All of them have a vested interest in MySQL.
Worse case is that we move to PostgreSQL (which we do to a large extent in core, though contributed modules are spotty), FireBird SQL, and SQLite ...
I guess that is what your crystal ball says. Mine does not say that yet.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba