Just a quick note to report that both my PostgreSQL 8.3.7 and MySQL 5.1.4 installs survived the upgrade to OS X Lion. PostgreSQL was installed via Mac Ports and MySQL was installed via the download from their website. PG Admin and MySQL workbench are also working just fine.
Last night I upgraded my MacBook Pro from Leopard to Snow Leopard. I used the upgrade method instead of the clean install. So far I cannot tell that anything is different. This really does look and feel like an under the hood upgrade. At this point I have not dug into Snow Leopard UI changes, but I have been testing software.
I've had PostgreSQL 8.3 installed on Leopard via MacPorts. Now that Snow Leopard is installed I just fired up PostgreSQL and it runs perfectly. I didn't have to do anything as far as reinstalling or fixing. Just after installing Snow Leopard I installed Xcode which is on the Snow Leopard DVD in the extras folder (I think that was the folder). I am not sure if that was needed to make PostgreSQL work, but I do know it is needed to install MacPorts in general because Xcode provides the GCC compiler.
Also, pgAdmin3 v1.10.0 is working just fine on Snow Leopard. I was able to reconnect to my PostgreSQL databases on my MacBook Pro as well as my production server. All on my data on the MacBook Pro was saved.
Next step is to check out my ColdFusion 8 server and Apache installs.
I've had to do this a few times and each time I have to dig around to get this just right so this time I decided to install and document what I did. I'm doing this install on Centos 5.2 64bit that is running in a VM (VMware Fusion) on my Mac Book Pro. This Centos install is also running a version of ColdFusion and Apache. I have two reasons for doing this install. One is so I can practice the upgrade from 8.1 to 8.3. There are some SQL functions in 8.3 I want to get into that lets you return ranks with your query. See this. And the next was so I could document this process so I don't have to search the net to find how to do it and then figure out how I need to do it. Since I maintain my own servers I tend to have to research this sort of thing a few times a year. I'm also planning to purchase a new to me server with much more power to run my production PostgreSQL DB and I figure I should have this part sorted out by the time I decide to spend the money on the machine.
So step one after figuring out the VM stuff (running VMware is new to me) is to install PostgreSQL. When I did my first PostgreSQL install ages ago I downloaded the source and ran a bunch of commands something along the lines of .configure --some-options; make; make install; and some other stuff. Now that I'm using Centos I figured why the heck do ALL of that when there is YUM! So I did yum:
In my description of this blog I wrote that I converted BlogCFC to work with PostgresSQL. It did not take much to make the conversion and the code is still fully compatible with the other versions of databases that are officially supported. There is absolutely no reason why PostgreSQL should not be supported.
So here are some examples of the changes I made. Most of the changes had to due with date functions and in most cases can be spotted in the code by looking for db type "PGSQL".
In the file blog.cfc version 5.9.002
First add PostgreSQL as a valid db type.
Many people ask me why I am using PostgreSQL. I tell them I've been using it for many years and found it to be much better than MySQL is many ways back in those days. Today MySQL has caught up on most fronts and PostgreSQL has gotten the led out and is much faster than ever before. The full details are here [http://www.postgresql.org/about/] and the interesting [history is here].
It used to be that MySQL didn't have support for transactions and rollbacks, stored procedures, triggers, or referential integrity and much more. From what I hear these issues are resolved in the current versions, however back when I needed these features PostgreSQL provided me the solution. Plus the power and speed is phenomenal. I see no reason to switch to any other ORDBMS now or any time in the future.