Archived News | PostgreSQL for Mac | Andy Satori

PostgreSQL 9 and 8.4.4 Now Available

Thu, 23 Sep 2010 22:52:13 -0400

So the new builds are available for download. There are a couple of things to note, so read up a bit before you go installing. First of all, there is no longer multiple installations for the two versions.

1. Everything is now in one installer. 9.0.0 is the default, but you can select the 8.4.4 version from the custom installation option.

2. The installer now goes to the /Library/PostgreSQL folder instead of /Library/PostgreSQL8. If you would like, you can move your existing folder to that location for an upgrade, or you can leave them in place side by side. Symlinks will work too.

3. We have dropped support for 10.4. As we migrate to use the newer features of the Cocoa platform, 10.4 is becoming increasingly difficult to keep in sync. With that in mind, we have dropped support for 10.4. We can support it if needed, but it is time consuming.

4. pgAdmin is now installed as part of the installation

5. The Automator Query actions are now installed by default.

6. JDBC4 is now in the installer, but it is an optional installation.

7. Symlinks are now correct with regards to doc and man.

8. pg_set_version.sh will no longer create bogus doc and man folder links.

PG 9.0 Builds in process

Tue, 21 Sep 2010 10:30:50 -0400

With the release of the official PostgreSQL 9 version on Monday, we are working to get the newest packages updated and posted.

New Laptop

Mon, 13 Sep 2010 21:13:34 -0400

Well, as I noted a few weeks ago, my laptop was having issues. It got a new logic board, but was never quite right after the repair. Because of that, I bit the bullet and purchased a new laptop last week. I purchased a Core i7 15" that should get me through another year or so. My machines take a bit of abuse between travel, daily use (though I have a desktop at the office, I prefer the laptop and having everything in one place) and commuting, I have never gotten more than 3 years of personal use out of any laptop. I generally try to retire them between 18-24 months, and rotate them to less stressful environments than mine so I can get another 18-24 months of use out of them. This last one did not make it a 15 months, and will only be suitable for rotation after it comes back from another trip to the Apple service center.

I note this here for two reasons. A. This is the reason for the delay in releases right now, moving from machine to machine is time consuming. B. Between the economy and the timing, it is an expense that was unexpected, which further impacts PGSQL time as I work on a getting a couple of contracts to fill the void.

So, yes, things are a little quite on the release front, but we are working on some cool new stuff.

One of the cool new stuff items is something we have been playing with for a little while, and that is another framework, and some example code for building RESTful services in Objective-C based upon PostgreSQL tables. Effectively, it is a RESTful query engine written in Objective-C, making it even easier to consume PostgreSQL Data from any platform and client.

PGSQLKit for iOS

Mon, 26 Jul 2010 20:46:41 -0400

Today we make available something new(ish). As we've posted in the past, we have been tinkering with PGSQLKit as an iOS library for accessing remote PostgreSQL servers. Please bear in mind, this is not the whole stack, it is just a client access library at this point.

In the spirit of being forthright about everything, we seriously considered holding this internally and making it a commercial product. Like most small businesses right now, we need the revenue. The problem is finding a balance between Open Source and revenue generation is proving to be a difficult one. This years total revenue to date from PostgreSQL (advertising and donations) is $126.58.

That said, in the spirit of what we want of this project we could not in good faith keep this as a commercial project. So here we go. As of today, PGSQLKit for iOS is part of the project.

In this first revision, the setup and deployment is still a pain in the arse. It will get better as we refine the process. Currently in the zip is a set of three other zips. ipsql.zip is nothing more than a sample of a simple iOS project that is built upon PGSQLKit. It shows how the files are included and used. The second is PGSQLKit.zip. This archive is the SVN tree of the PGSQLKit code, the needed files will need to be added to your project from here. Finally is the biggie, pqtouch.zip. In this archive is the xcode project to build libpq from the PostgreSQL sources for iOS. An entire PostgreSQL source tree exists in the folder, as there is some work in progress at getting PostgreSQL itself running on iOS. That is work that will continue, but is a VERY low priority.

When we update the mainline distribution to PostgreSQL 9, this too will be updated.

Good luck and have fun coding.

9.0 beta 3, 8.4.4 and 7.4.29

Mon, 19 Jul 2010 10:16:21 -0400

On the agenda for this week is getting the packages updated for the new versions. We are starting with the oldest and working forward. For the most part this is fairly straightforward work, but after the problems with the .pkg from 8.4.3, we have to do some testing and debugging on the packages that may take more time than we expect.

PGSQLKit, iPad, PostgreSQL9

Tue, 06 Jul 2010 14:51:12 -0400

Tackling a few subjects here, so this might be a bigger post than usual.

First, there has been some work with PGSQLKit over the last couple of months that we need to talk about. While much of the work has revolved around getting everything working so that the iPhone / iPad can be used as clients to a PostgreSQL database, there has also been a good bit of work to address several other issues. One that comes up fairly often is the ability to store binary data. Though we haven't finished the PreparedStatement work (we still haven't found a solution for this we really like), we did add a pair of new functions to the PGSQLConnection object to make it easier to manage binary data.

-(NSData *)sqlDecodeData:(NSData *)toDecode;

-(NSString *)sqlEncodeData:(NSData *)toEncode;

These two functions work in tandem to encode and decode binary data for use in sql commands. While storing large amounts of data in binary form is not really what PostgreSQL is designed for, it works well for small amounts of binary data.

In addition, all of the objects have been altered to allow for better support of string encodings. For PostgreSQL9, we are moving towards using a local platform mapping to determine a default encoding based upon your locale. Most programs that use PGSQLKit will need to call setDefaultEncoding: to ensure correct string encoding operations as the defaults will change to NSUTF8String with PostgreSQL9.

iPad / iOS

The iPad and iOS4 platforms present some interesting issues for us. At this point, everything in PGSQLKit but PGSQLLogin works on iOS3 and iOS4. However, because frameworks are not supported, the classes have to be imported as source. We hope to have a sample project uploaded in the coming months to show how all of this works.

The flip side to this however, is the server. We get frequent requests to run PostgreSQL itself on the iPad. Though in our testing, it is something that *could* be done we are not entirely sure if that translates to *should*. First, battery life would be impacted. Second, for single user needs, is this necessarily a good answer? Third, assuming that it was all configured and running, what are the real applications the PostgreSQL engine on the iPad?

At this point, we do not have good answers, and so this part of the project will, for the immediate future at least, remain more of a theoretical / proof of concept project. If we see a compelling reason to change this, we will.

PostgreSQL9

With PostgreSQL9 having recently moved to Beta2 stages, we are expecting a release sooner than later. This means that we are gearing up to deliver a new installer, that hopefully addresses most of the weaknesses of the current approach. At this point, we think we will have something ready to go about 4 weeks after the official PostgreSQL9 release, but as always, the paying work will take precedence.

This weekend :(

Fri, 30 Apr 2010 12:06:53 -0400

Unfortunately, we are in a tough spot for the weekend. As most of you know, I (dru) do that vast majority of the work in the project. Unfortunately, my primary machine suffered a major failure last night. My Mid 2009 MacBook Pro apparently cooked it's GPU. So it is now a glorified paperweight that requires a new logic board.

Obviously, that leaves me without a mobile to work from home on.

Though I have shipped the machine to Apple this morning, I do not know how soon I will get it back, nor am I entirely certain I will. It is *very* close to the 'not in warranty' time in it's lifecycle. If it is not warranted, then I will be faced with a nasty choice. $$$ to repair or $$$$ to replace, both at a time when things are a little lean around the checkbook parts (having just purchased iPads for development purposes earlier this month). Given that, the work towards 8.4.3 will be heavily impacted this weekend and well into next week.

I will try to keep this updated as I have more information. If we get the predicted rain, I may come in o the office and work here over the weekend to get this moving.

Time Away to Rethink Installers, PostgreSQL

Tue, 27 Apr 2010 17:29:45 -0400

First let me apologize for dropping off the face of the earth for the last 3-4 weeks. Paying work got a little nuts and then we ran into our annual user group meetings for those same customers. Between those, that pretty much killed a month.

That said, it really turned out to be a net positive, because it gave me a bit of time away from the current state of affairs to really sort out where we need to go with this. To really gnaw on some of the core issues that surround this project in specific, but also PostgreSQL as a whole. It also let me sort out where I think this project needs to go with regards to those issues.

Earlier this year, I created a PostgreSQL steering committee. Ultimately, they will help make some of these decisions, but I am going to lay out my thoughts here and now, and we can all take it from there. First we need to tackle the issues (as I see them).

The Issues

Lack of external tracking of issues

The strength of PostgreSQL may well be one of it's greatest weaknesses. The distributed 'work on what you want' nature of Open Source development means that sometimes issues can sit for a long time before they get addressed. To make matters worse, PostgreSQL has elected not to use an issue tracking system like Bugzilla, but has instead chosen to use a mailing list for tracking bugs. This can make it tricky to filter out what is or is not being worked on. I know of a couple of issues that I have elected not to work on because I believed them to be in process based upon -bugs and -hackers mail traffic. One has existed for a while and has not been addressed. I know that those effected are looking at alternative platforms to PostgreSQL because they have no way of knowing if an issue is being worked on.

This means that people that are not active on both -bugs and -hackers have no way to 'track' or 'watch' issues once they have been reported. It also means that some of us that are not full-time on the PostgreSQL mailing lists sometimes have difficulty monitoring the status of a particular issue. I do not see this changing within the PostgreSQL.org environment.

Granularity of Focus

This is not a PostgreSQL issue so much as it is an issue with this project. The initial goal and mindset of this project was very narrow. Build PostgreSQL with the most common options and configure it so that it fit naturally into the Mac OS environment and ecosystem. I think we accomplished that, and then the scope grew into the GUI tools, and then the developers frameworks. Somewhere along the we, that narrow focus either got lost or misplaced.

Apple's Installer is not well suited to the PostgreSQL for Mac Project

Do not misunderstand, the Installer.app is a nice tool, but for a project that has so many updates, and such a massive base of potential add on modules, it is not well suited to the need. What is needed is something that has more in common with the package managers or Sparkle than Installer.app.

No central repository for the modules and addons for PostgreSQL

This is an old problem. There is a repository in pgFoundry, if you build from source. You can also use DarwinPorts or Fink to install everything, but there are issues with all of the above. Not the least is that most servers do not have the Developer Tools installed on them. It also means an additional learning curve for many people that are not prepared to, or are outright afraid to tackle.

Dealing with the Issues

There is no silver bullet here, and honestly we are a very small fish in the pond, even in the smaller Mac Using PostgreSQL pond. So the scope of what we *can* tackle is relatively limited. Acknowledging that, it occurs to us that what we can do is tackle each of these topics in our little corner of the pond.

Lack of external tracking of issues

Unfortunately, there are limits to what issues we can tackle in the trunk code base. What we can tackle though, we can track. Though I am not the worlds biggest fan of SourceForge, that is where we set up shop for PostgreSQLforMac 6 years ago. It makes no sense to go elsewhere at this point, despite my own preference for a JIRa/Confluence/Bamboo configuration. We can start tracking issues that we are either 'tracking' on -bugs and -hackers or are working internally. This gives our customers a place to go o track issues that have been reported directly to us.

(Francois, if you would resubmit your history on your Collation bug, we think we would like to start with that one)

We know that this will never percolate to the larger PostgreSQL community, the discussions there regarding bug tracking systems are just not worth rehashing. Suffice it to say, they will choose to do what they choose to do.

Granularity of Focus

This is really a tough one. The truth is, we would really like to be a one stop shop for all things PostgreSQL on the Mac. This would require a time commitment that our PostgreSQL derived income simply cannot support. Understanding this, we think that solving the next issue will actually help with this while making the real desire a little bit more attainable. In the short term though, the focus almost has to go back to the original goal, along with a smaller subset of the tools to make it all work. The other fluff pretty much has to go back being paid for work until the total revenue is sufficient to support it. Sadly, it comes back tot he 'making money on Open Source is tough' comments that you are seeing in mainstream tech media right now.

Apple's Installer is not well suited to the PostgreSQL for Mac Project & No central repository for the modules and addons for PostgreSQL

This one, and the next one are tightly wound together, so we are 'bundling' them together. The solution to one, quite naturally links to the other.

The more we fight with Installer.app and how it overwrites directories, the more evident it becomes that Installer.app just doesn't work for what we want to do. Before we get into the details, we need to give some background.

If you have looked inside the /PostgreSQL8/ folder lately, you will have noticed that it's internal structure is built to support multiple versions in the same folder that can be 'switched' at the users discretion. This idea is to allow developers and deployers both to easily switch between minor versions without a major hassle of backup/uninstall/reinstall/restore. We would really like to also make it trivial to do the same with the various 'addon' modules that PostgreSQL supports (think PostGIS as a 'for instance').

We have spent months trying to work within the limitations of Installer.app to accomplish this, and yet the harder we push it, the worse it behaves.

For that last couple of months, we have been tossing around the idea of doing something else for the future installs. The 8.4.3 installer failures have only pushed this idea harder. After a few weeks away, I am sold.

What we want to do is add a PostgreSQL Installation Manager to the distribution. Using it, you can install a PostgreSQL version from a locally stored package, or from a Server based package that we provide. The process works like this:

A. User downloads the 'unified installer'. It installs the installation manager and a small collection of local packages (current version, gui tools, etc). Once complete, it allows the user to select add ons that may be wanted, directly from the PostgreSQL for Mac Repository. When a new version is released, it works like Sparkle, enabling a self update, while retaining your current version. You can then choose to 'test' a new version and roll back quickly if it doesn't work out. When you are done with a version, you can easily remove it.

Yes, this is a ton of work. In the long run though, it provides a blueprint for something that can be the centerpiece of the best Mac Database solution on the market, and that is what we want.

But what does that mean in the short term? well, it means that a fixed 8.4.3 has to be dealt with. Probably this weekend. It also mean that 9.0 is the earliest we would see this. There are a couple of other changes that have to be dealt with for 9.0 anyways, but that is a topic for another book :).

Regardless, we are not going to tackle this until we get some thoughts from you the users, so please post up, or email me. We need to work on some design stuff, at this point everything is pie in the sky concept stuff.

For users with 8.4.3 already installer

Mon, 29 Mar 2010 20:36:47 -0400

There is a quick way to get an 8.4.3 installation that failed working. Open Terminal.app and run the following:

cd /Library/PostgreSQL8/bin

sudo ln -s postgres postmaster

cd ../lib

sudo ln -s libecpg.6.1.dylib libecpg.6.dylib

sudo ln -s libecpg.6.1.dylib libecpg.dylib

sudo ln -s libecpg_compat.3.1.dylib libecpg_compat.3.dylib

sudo ln -s libecpg_compat.3.1.dylib libecpg_compat.dylib

sudo ln -s libpgtypes.3.1.dylib libpgtypes.3.dylib

sudo ln -s libpgtypes.3.1.dylib libpgtypes.dylib

sudo ln -s libpq.5.2.dylib libpq.5.dylib

sudo ln -s libpq.5.2.dylib libpq.dylib

exit

That will recreate the missing files from the distro.

Issues with 8.4.3, Resolution incoming

Mon, 29 Mar 2010 11:12:12 -0400

The 8.4.3 release over the weekend has a major issue. Somehow, the symlinks are being dropped from the 8.4.3 installation. All of the files are there, but not the links. This is causing failures in launching and using.

Now that we know the issue we've got a fix in process and hope to have the package updated later today.

Released 8.4.3 and 8.3.10

Sat, 27 Mar 2010 19:03:50 -0400

Both of the updated installers are now available. These are just updates to the core DB with few other changes.

One caveat though. There is an issue in the installers that rather than leave a current version in place, the installer overwrites them. We are not entirely sure how to fix the problem, but there are a couple of options we are exploring. If you need the prior version to stay put, please copy it aside and then copy it back in after the installation.

8.4.3 building now; release this week

Mon, 22 Mar 2010 17:56:51 -0400

Just a quick note that with the weekend release of 8.4.3 and 8.3.10 we are already in process with these releases to update the distro. Expect a release this week, but it means that we will not be ready with nQuery for the iPad before the app store cutoff for the launch.

Back with more as we have news.

Another week, another update

Thu, 18 Mar 2010 11:45:02 -0400

So this week has seen a handful of additional changes to PGSQLKit. PGSQLKit 8.4.2c has been published with this posting. As we work forward with getting our iPhoneOS work done, we have been spending a lot of time in PGSQLKit (as it is what we are using in the iPhoneOS world). That time has seen us finding little issues but also time to make some needed tweaks.

Most of our work right now is subtle changes like replacing NSMutableStrings that aren't with NSStrings, or identifying release/retain pairs that are not properly matched. Some of the work though is addressing issues raised. If you have been following some of the discussions in the comments of the recent posts, you'll see that we have had the string encoding bugbear rise again.

String Encoding

We addressed this in a simple form not too long ago, but it was just that, a simple quick answer. This update addresses the situation in a more complete way, and lays the groundwork for the future with regards to future usage. The downside is that people using the PGSQLKit today that expect a certain behavior will need to adjust to something new when PostgreSQL 9 is available.

The fundamental change is that effective with 8.4.2c, PGSQLKit now implements a defaultEncoding on all of the objects, starting at the PGSQLConnection object. The default is NSMacOSRomanStringEncoding to remain consistent with the old behavior. Please note, THIS WILL CHANGE WITH PostgreSQL 9.

If you change the defaultEncoding before opening a PGSQLRecordset, all of the string operations on will adopt the new default. Existing PGSQLRecordsets will not be effected, but can be changed by setting their respective defaultEncodings.

What this means is that if defaultEncoding is changed, then all string operations will use the new encoding unless explicitly overriden in cases like using PGSQLFields asString:(NSStringEncoding)encoding method. It also means that using dictionaryFromRecord will return strings using the defaultEncoding.

The defaultEncoding can be altered at any level and always cascades down: Connection -> Recordset -> Record -> Field.

This solution should provide enough power and flexability to deal with most any encoding issues in the future.

Now about the change:

With PostgreSQL 9, the default value for defaultEncoding will change from NSMacOSRomanStringEncoding to NSUTF8StringEncoding.

Documentation

As we continue the work, we are expanding the headerDoc documentation. This documentation is included in the PGSQLKit download, and will eventually find it to the website. The only reason it is not there now is that we have not had the time (or inclination to be honest) to sit down with a CSS editor to really clean up the layouts. It will happen, it just hasn't yet. If someone with a flair for CSS and HeaderDoc has the time and inclination, I promise we won't complain :-).

libpqtouch?

So, unless you didn't catch it, libpqtouch is a version of libpq compiled as a static library that we are using as the foundation of PGSQLKit for the iPhoneOS. The discussion around the office is how to handle this. Right now, the project is a manually updated build of libpq that is built in Xcode to create an armv6 build of libpq. None of us have been able to get a good build of libpq directly from the command line using PostgreSQL sources without eventually hand assembling the files.

This makes it very difficult to publish the changes back to the PostgreSQL community. So, what we are proposing is this: Publish the steps and the Xcode project. Until things stabilize with our project, we are holding on to the work, but hope to get it into the public SVN as soon as we submit the iPad application to the iTunes App Store.

Updated PGSQLKit & other rumblings

Sun, 14 Mar 2010 22:29:54 -0400

Uploaded a new PGSQLKit today. It is tagged as 8.4.2b. The changes are minor unless you need them. The addition is an encoding parameter to the asString methods.

The other rumblings however may have interest to some. Over the last few months we have been tinkering with libpq, PSQLKit and the iPhoneOS. In all candor, we have had the underlying bits and pieces up an running on the iPhone/iPod Touch for a couple of months, but really did not see much market for it. The iPad really changes that game.

Because of that we are announcing that in the next 3-4 weeks Druware will be releasing it's first iPhone / iPad app, and it is a PostgreSQL application. Dubbed nQuery Mobile, it is a simple PostgreSQL query app designed to store and run queries against TCP/IP connected PostgreSQL Servers. It will be lightweight, and barring any problems in the App Store approvals process, we hope to see it available for $14.99.

This is particularly relevant, as all of the revenue for this version of nQuery will go directly to keeping development efforts on this project expanding.

Enhancing PGSQLKit

Mon, 01 Mar 2010 12:42:58 -0500

Now that we have the major hurdle of getting the base PostgreSQL distribution back up to current code, we can now tackle the long desired enhancements to the PGSQLKit.

As I see it, there are four projects that need to be addressed in the PGSQLKit as is stands. First and foremost is documentation. Second is to enhance the system to better cope with String Encodings (in both default and per use forms). Third is to establish a better method for binding a recordset to an Array. Fourth is to implemented an object and method for using Prepared Statements.

Two of these are relatively straightforward. The other two are pretty massive undertakings.

Documentation pretty much has to be the highest priority, and it needs to come in two forms. It needs to be easily used on the development machine, but it also needs to readily available on the web. The former can be addressed with the already begun move to using HeaderDoc, but the second is a manual process as it will require some work to convert the HeaderDocs into something that is easily integrated into the website.

The String enhancements may actually be released before the documentation, simply because much of the work is already in place. We have already done the work in ODBCKit, so translating that to the PGSQLkit really isn't that much work.

Dealing with the bindings issue is a little more complex. At the heart of the issue is be nature a recordset is a largely a forward read environment. In order to make this a data source, it would need to prefetch the content. While this is feasable for smaller results, when we start talking 1.2 million records at 30kb per record, it suddenly becomes a nightmare. After some discussions regarding the potential pitfalls, we really do not have a consensus answer. The easy answer is to simply say, create a Data Source class that can be fetched off a recordset. and let the developer deal with the consequences of creating a DataSource that contains too much data.

The second part of this is, should a DataSource be updatable? This is a tricky one. Eventually, it should be allowed (where possible) but it starts into a bit of code that is much more prone to error than anything read only. This will not be a part of the first pass at this.

Last is the implementation of Prepared Statements. Honestly, if someone else wants to tackle this, feel free to speak up. We have been through 4 iterations of design on this for the ODBCKit and none have been good solutions. They are either too complex, or not powerful enough. There does not seem to be a reasonable middle ground.

Also of note, the next major version of PostgreSQL is no longer labeled as 8.5, it is now 9.0 and has started Alpha level testing. With that launch, we will move the PostgreSQL8 folder to PostgreSQL/versions/ to ease future transitions.

8.4.2, 8.3.9 Released & What is next?

Thu, 25 Feb 2010 16:39:04 -0500

First of all, today we published the latest versions of the PostgreSQL 8 codebase. This only puts us about a month and half behind most of the distributions, but as explained in our last post, this is the result of our experience of the last several months from using code that was built using the cross platform build process on a single machine. We broke everything apart and redesigned our build structure specifically to tackle these quirks. Hopefully, this means that platform specific errors and quirks are a thing of the past. If they are not, we will deal with them as they come up.

With this release there are some other changes to note. First, PGSQLKit is now available in the Developer's folder of the Unified Installer Disk Image, as well as in it's own download. Along with the PGSQLKit getting it's own folder, it also is migrating to a header based documentation, and those documents are contained in the Developer folder as well.

The other notable change is a website change. Starting today, we are switching over to a new comment provider. Our old one, Haloscan, has shut down, and the replacement, Echo, just doesn't offer enough features for us to follow over. Instead we have moved to Disqus for the comments. At this point, we are not entirely sure how the old comments will import. We will see in a few days if it is nice and clean. If not, we will figure something else out.

But what is next?

Well, several things all at once actually.

Since the iPad announcement, we have been tinkering with some work derived from an experiement we did getting libpq and PSQLKit running on the iPhone. The problem was that we really didn't see much use for either on the iPhone. The iPad though, has potential for usage as an interface to PostgreSQL data directly. So that experiment has been reworked a little to see if we can get it all working on the iPad. Initial results are positive, so that project will likely continue to get some attention until we can get our hands on a real device to see if our assumptions about usability and applicability are correct (we think they are).

In addition, Dru and the gang at Druware have started a new project that is the first truly consumer oriented project they have tackled. It is built on PostgreSQL, and they hope to turn it into a bit of a poster child for the power of PostgreSQL. That project itself is expected to take a year or more before it is publicly available, but some of the fruits of that work are already trickling back.

One of the highlights of that effort is the successful relocation and embedding of PostgreSQL into a stand alone application. Meaning that contained within the .app bundle is not only their application, but also a fully functional copy of PostgreSQL that starts, vacuums and stops with the application. The potential usages of this are pretty significant. In this instance, it only uses this model for the single user product of the multi-user capable product, but by enabling this functionality, this makes PostgreSQL the ultimate in scalability, from single user drag and drop installations, to PostgreSQL for Mac multi-user installs all the way up to large scale Sun or Linux hardware dedicated to PostgreSQL.

Last but not least is the beginning of a migration to a new web server for the PostgreSQL project. At the end of 2009, we were given the difference between our donations from 2008 and 2009 and the price a new Mac Mini Server by Druware to acquire a new Mac Mini Server. This wiped out the accumulated donations, so we are back to $0 in the donation account, but allows us to move the PostgreSQL site to it's new home on Mac Mini Server. The full transition probably will not happen for another couple of weeks, but it too is coming soon.

Releases Incoming

Thu, 18 Feb 2010 18:53:03 -0500

Just to let everyone know, I expect to finish publishing the current releases during the day Friday. Both 8.3.9 and 8.4.2 are built with the major UTF8 and Johab bug fixed. At this point, the changes to address an issue with collation on Mac OS X (shared by all of the BSD based variants as far as I know) are being held back until we get more testing done on the changes.

A huge part of the delay is that the build process for this distribution is a very time consuming process, and the 8.4.x tree has really caused the old automated system fits. I guess in order to explain this properly we need to shed some light on the whole process.

Building PostgreSQL for Mac as a distribution is 8 separate iterations of the build for each version. 2 iterations each on 4 different machines. Complex? that's the easy part. Once all of the iterations are run, they have to be stripped and reassembled as universal binaries, merged from all of the build iteratations. Then the finished product has to go back to each of the 4 machines to test the finished product. The reason for this is quite simple. If you don't build on the architecture you want to run on, the build process makes decisions based upon the current architecture. That can and will cause unexpected behaviors in the resulting binaries (like endian issues, or header files without out of order data structs).

The current setup has a 10.4.11 Mac Mini G4 as the 32bit PPC build box. Then old semi-retired PowerMac G5 running 10.5.8 does the 64bit PPC build. For the 32bit x86 (i386) build, we have a 1st generation Intel iMac running 10.5.8 and finally for the x86_64 build we have either a LED 24" iMac or my MacBook Pro laptop both running 10.6.2.

Each machine runs the same script to download and build the latest versions (Build.Distro.sh in svn). That script, downloads the latest and then next back, so for example, today it pulls 8.4.3 and 8.3.9. It then builds each version twice, once dynamic for the /Library/PostgreSQL8 path, and once for the static libraries used by the PGSQLKit in /opt/local. Once built, the output goes to a merge folder on a NAS device. Then comes the hard part.

One of the quirks of the build process is that every file in the resulting tree is single architecture, except one. That one is pgperl.so. That exception creates all kinds of hassles, since you can use lipo to merge a Universal binary to create a new universal binary, you have to first excise the distinct binary into a non-fat binary. We fought with the scripts to do this reliably for a month. It never worked right in the shell scripts, largely because of the way lipo writes to stdout and stderr. Ultimately, we ended up gutting that function out into an Automator Workflow / Applet that takes the file as a paramter and does all the work to thin the file for us. ( you will be able get the workflow from the Druware website shortly).

Finally there is the 'Merge' script that takes all of the files and reassembles them into the Universal builds. That is not checked into svn at the moment, but should be by the time the releases are published friday. After fighting with a nasty bash script to do this, we ended up using a modified version of the old AppleScript / Automator Workflow to do the merge.

At this point, the build process still has a few manual elements, but the worst parts are automated again. Hopefully, this means things smooth back out in timing releases with main tree releases.

Status Update

Fri, 18 Dec 2009 11:28:27 -0500

During the last couple weeks several little issues with the current installers have come up. All have roots in the attempts to build a single binary that addresses support for 10.3.8 on PowerPC, 10.5 PowerPC 64bit and, Intel 32 and 64bit support. I am certain that for smaller, less complex projects than PostgreSQL, this is not a problem, but we are finding that maintaining 10.3 support has become a major problem.

We would really like to drop support for 10.3. If we cannot resolve the problems with the build system and 10.3 today, we will be dropping support for it with the next update release, due in the coming week.

The second bit is that we have to address the upgrade process.

This is an issue that has been lurking around the fringes for a long time. Today, there is not a good upgrade path and option within the installer. This is something that really has to be addressed, and soon. While we haven't even begun to really tackle this issue, I think it has to be a priority.

Therein lies the crux of the issues that the project faces. Most of what is going on is because it is what I think. Because of that, I have decided to create a steering committee of several people from the community plus myself. The intent is to form a group that will provide direction and priorities for the project as a whole. In essence, the project has grown in scope well beyond scratching an itch and into providing a foundation for the Mac community as a whole.

As the Mac continues is growth into the business marketplace, our place in that community is only going to grow. I would like to proactively place this project into the communities hands, instead of just my itch. With that said, I am not a person that will not express an opinion, and being open source, contributors may still focus on tangents, but the project as a whole will be governed by the wishes of the Steering Committee. If you would like to participate, and have not received and invitation via email, please let me know. This is certainly not going to be a free for all, there are limits to the number of people that will be participating in this group, but I will do my best to be as inclusive as possible.

8.5, 8.4.2 and 8.3.9 ?

Wed, 18 Nov 2009 09:51:55 -0500

It looks like the first test releases of 8.5 are starting to make appearances from the official sources. Given that, I am assuming (yes I know about that word) that we will be seeing new releases of the current and older releases in the near future. As we have had some issues with our current build system, we are starting the process of building a new build system here are the office to try and streamline the process. The new build system consists of 2 Mac Mini's and a new set of scripts to do nightly builds. Ideally, we would like to have a couple of additional machines to use as test machines, but that is not in the budget at this point.

It is our hope that by dedicating a couple of machines to the build process some of the issues that have plagued our current build process (scripts that are run on whichever development machine is available) will be resolved.

More news as we get everything configured, but we feel this should help quite a bit.

Bugs found, updates coming

Wed, 28 Oct 2009 20:18:38 -0400

Got a support request in today that pointed out a pair of issues in the current release. For some reason, two of the shared libraries did not get properly merged into a 32/64 bit universal binary and only contains the 64 bit versions. We are rebuilding now and should know what the problem is in a little bit.

In addition, it appears that there is a situation in the installer where an existing installation can get overwritten. This is also being investigated and as soon as we have a solution we will be updating the installers.

Oh, and we went ahead and switched to the new page layout for the site. The old one was starting to feel stale.

Oops, 8.4.1 updated.

Tue, 13 Oct 2009 21:36:11 -0400

I grabbed the wrong build and it is broken. I am uploading a new one now. If you downloaded before this update, you can fix the install by typing:

sudo /Library/PostgreSQL8/pg_set_version.sh 8.4.1

8.3.8 & 8.4.1 Available - A couple of other notes

Tue, 13 Oct 2009 15:08:39 -0400

Both the 8.3.8 and 8.4.1 releases have been updated and released today. Downloadable from here, these two installers are the wrapped around the latest PG cores, but also include some enhancements to the Preference Pane that make it more Snow Leopard friendly.

This release also marks the move to a new directory structure to allow multiple versions and a quick way to switch between them in the form of the pg_set_version.sh shell script. Eventually this will be part of the Preference Pane.

So, back a few months ago, some comments were made that this project not continue due to the availability and tacit 'official' status of the EnterpriseDB installers. That raised some concerns among some users. There has also been a fair amount of email traffic over the delay in getting 8.4.1 and 8.3.8 released.

Let us clarify some things. This project is built and managed by two people. I won't speak for the other person, but I can an will say that this is not something that either of us make any real money off of. We have done zero (paid) consulting with regards to this project. Donations and advertising revenue (which have been quite open about) has generated roughly $500 above the raw hosting expenses ($120 / year) in the 5 years this project has been active. This is not per year, this is total. Needless to say, we keep doing this because we want to.

So, the future is simple. We do it because we want to, but sometimes the release schedules will have to float around the real life schedules and jobs that allow us to do the work. The only way this becomes a full time deal is we could find enough people to make significant ($1000 or better) annual contributions to allow one or both of us to switch to PostgreSQL for Mac as a full time job. Doing so would allow us to fulfill our personal dreams of building the PostgreSQL environment into a rich GUI environment that would compete with MSSQL favorably.

So no, the project is not dead, but it does ebb and flow as time allows and permits, and in that time we continue to work towards finding ways to make our vision come true. The other hurdle, is that we want it to remain Open Source and as free as possible, which has been the deal killer on both prior proposals for us to take full time jobs to enhance this project.

Good News!

Fri, 09 Oct 2009 11:47:12 -0400

After much pain and suffering the problem with the Snow Leopard version of the Preference Pane has been found and fixed. With that done, the release can start moving forward again. The test environment is being updated as I type this and should yield a result this weekend.

Getting back to work

Tue, 29 Sep 2009 18:05:12 -0400

Alright, today was the first day back with some time on PostgreSQL. We got both 8.3.8 and 8.4.0 built and into the test environments. That is the good news. Now for the bad. The Preference Pane is really broken on Snow Leopard right now. I am going to work on that tonight and some tomorrow, and if I can get it working, it will go into the release. If not, then we get to live with the 32bit version of the Preference Pane for a few weeks.

One of the big changes in this coming release is actually a long requested one. The ability to maintain multiple versions side by side (only one running at a time). STarting with this release the current version will install into /Library/PostgreSQL8/versions/current_version_number/* the bin, lib, share and other directories will be symlinked to the current version. Included in the distribution will be a shell script pg_set_version.sh that will allow you to select any installed version and change it if PostgreSQL is not running. This also means that we will NOT be upgrading your current data directory. You have to do that yourself (for the moment).

So how will you change it? easy, open Terminal.app and type sudo /Library/PostgreSQL8/pg_set_version.sh 8.4.0 to revert to your 8.4.0 installation. Eventually this will also be part of the preference pane.

So with all of that said, look for the new builds to hit the server sometime after October 1.

2 Weeks Away

Tue, 08 Sep 2009 14:23:37 -0400

Just wanted to let everyone know that the next 2 weeks are about as full as they can get for us. Due to that, we will not be able to get any changes done on the PG for Mac work until the last week of September. We hope to have 8.4.1 out right at the end of September!

64bit, Garbage Collection and 10.6 fun

Sat, 22 Aug 2009 11:52:23 -0400

Well, the last week has been spent working on getting things ready for 8.4.1 and a Snow Leopard ready release. For the most part things have been fairly straightforward. PGSQLKit is now GC enabled and built as a 64/32 Universal binary, The various GUI tools as well, with the exception of the Query Tool and the Preference Pane.

Unfortunately, the Preference Pane has been non-trivial to resolve. The last three days have been focused on getting it working. At this point, we have the major hurdles cleared, and have moved into the clean up and refining stage, so that should be ready to go next week (admittedly in it's incomplete form, but usable for basic purposes). Query Tool may remain 32 bit for a while.

One of the big gotchas that cropped up was that preference pane's now require Garbage Collection. That change may preclude us from having a 10.4 supported pane in the next release. There are some tweaks we can apply, but time may become the issue. I will post here when we know more.

Next up is stating the installer builds to make sure that they work well, and to make them clean up the old paths a little better.

Moving forward

Mon, 17 Aug 2009 22:06:18 -0400

The past month has been interesting around here. Snow Leopard has been getting closer, and we have been working on some design things in the PGSQLKit / ODBCKit frameworks. This work has been centered around three distinct tasks.

The first task is one of optimization and bounds checking. The short version here is that we have known for a while that both toolkits had a memory leak. Doing some digging, and the leaks have been found and exterminated in the ODBCKit and we are now working through the same items on the PGSQLKit. That work should improve performance and stability, but also paved the way for the second task.

So the second task, was turning on garbage collection for both frameworks. This is generally just a compiler flag, however, in this case it also means changing some calls in the frameworks to stop using some old API calls. Cleaning those up has allowed the GC flags to be supported in the ODBCKit and again, those changes are now being reflected in the PGSQLKit.

Finally, the third task has been revolving around getting finishing the prepared statement support. This work is still a couple of more weeks from finished, but is beginning to be usable.

All of this adds up to a new release of the PostgreSQL for Mac packages in about 3 weeks. Hopefully this will coincide with an 8.4.1 release, but we will not be delaying to wait upon it.

Tangents

Wed, 15 Jul 2009 01:00:30 -0400

A few days ago I mentioned that there was some work going on to try and generate some revenue from this project. One of those efforts led down a side tangent, the result?

Well, you can look for yourself. What you see is an app running in the simulator, next to it's nib, next to the source. What does it mean?

We have gotten PGSQLKit running on the iPhone 3.0 SDK simulator. What this means, is that we can now build native client applications on the iPhone and iPod Touch that connect directly to PostgreSQL.

Unfortunately, this is not completed work, the connections right now are 'in the clear'. No Kerberos, no OpenSSL, no LDAP, no GSSAPI. We are focusing on OpenSSL first. Once that is working, the next step is to test it all on the iPhone native, shortly followed by turning the test app into a quick tool for running quick ad-hoc queries, completely wirelessly.

Needless to say, the potential for business development using this is pretty interesting, particularly for businesses that have not migrated to SOA or n-tier configurations that would like to leverage the iPhone OS platforms as solutions. We are pretty excited about this, and yes this is where most of our free time has gone of late.

Houston, We have a problem

Sat, 11 Jul 2009 12:00:37 -0400

Somehow in the process of uploading, Disk Utility managed to munge the file system of the compressed Disk Image. This caused all the downloads to fail with unmountable filesystems. Making matters worse, we tested using the master, not the compressed so we did not catch the problem.

As of now, there is a new download here, and assuming it works a replacement will go on sourceforge later today.

8.4.0 is on the server

Wed, 08 Jul 2009 16:26:15 -0400

And slowly appearing on the SourceForge Tracker. This release includes some changes to the preference pane, but there is still work being done on some design ideas. Though it is usable at it's basic stage, there is still more that we can't turn on yet.

It should address several issues with the installer. Though the core libraries and server are now 64bit, the GUI tools are not. This is to maintain compatibility with 10.4. We will likely transition to 10.5 as the minimum supported platform as 10.6 becomes widely available.

Found!

Wed, 08 Jul 2009 10:01:50 -0400

One of the issues that has been plaguing the PostgreSQL Installer since the introduction of the Preference Pane has been a bug where people with older versions of the Preference Pane would sometimes get either a failed installation, or not get the current version of the preference pane.

This has been a *very* bothersome issue that we have been unable to solve until this morning.

The problem is a cache file that Apple creates. (~)/Library/Caches/com.apple.preferences.cache needs to be deleted when this problem occurs. This will resolve the installation problem. We are now looking at a good way to integrate that into the installer itself to resolve the issues.

8.4 Progress?

Mon, 06 Jul 2009 10:35:41 -0400

Over the weekend, we got a test build of the 8.4 work done. Initial testing looks good. Assuming everything continues to look good on all of the test machines, we should have a published release late this week.

PostgreSQL 8.4

Wed, 24 Jun 2009 15:54:46 -0400

With the official release of 8.4 around the corner, we have been testing 8.4 internally and things are looking really good. It is amazing how each revision keeps adding incremental changes and improvements. For us this is going to be an interesting release to see how things go. If the trend with the downloads continues down, we will make a decision as to keeping this one going, but for the moment we will stay the course.

I suspect that the 8.4 builds will be the end of our PowerPC support though. We are down to a single PowerPC left in the offices, and will not have anything to test on when it is retired in January. It is possible that we'll move one of the old Mini cluster machines to a developer desk to keep a build machine. Tentatively the plan is to have a PowerPC/i386 build that is 10.4.9 and an x86_64 build that is 10.5+.

We are expecting PostgreSQL itself to move to release status in the next 2 weeks and we hope to follow that fairly quickly.

The Future?

Tue, 16 Jun 2009 10:32:53 -0400

Like many other people in the US, the current economic issues have made me tighten my belt. That has had a major impact upon my free time. It is in places like this that the impact is most notable. If you have been monitoring SVN commits, you will have noticed that there has been no activity in a couple of weeks. Unfortunately, this trend will continue for at least 2 more weeks.

The reason is that I have had to trim some staff in the office, and that means taking up some of that slack personally. When that happens, projects that don't generate revenue tend to slide.

What does this really mean to you, the user? not much really. We should have an 8.4 release within a few days of the official release, and there will continue to be some forward progress on the other tools. The exception to the above statement is the Preference Pane. That has been seeing a bunch of experimentation behind the scenes. I am not entirely sure where it is going at this point. The short version is that after a bunch of ideas and experiments, we are looking at making it something that can be used with most PostgreSQL installations, not just ours. The base work is largely done, but there remains a lot of fine tuning, and that takes time.

The other change that is coming this fall, is that we are going to start redirecting this site back to Druware. The demands of maintaining multiple websites is another time consumer that just needs to go away. There will be more information as we get closer to that rollover, so there is no need to worry about it yet, just to be aware of it.

8.4, Installer and Other Tidbits

Tue, 21 Apr 2009 14:06:56 -0400

So if you follow the official PostgreSQL community, you will already know that version 8.4 is in beta and will likely be released in the coming months. This means it is quickly coming time for a new installer, one that addresses the current issues and includes the new one. We've started building the beta internally, and things look bright. The installer on the other hand is proving to be incredibly frustrating.

The issue is that Apple's installer attempts to relocate things to where the user may have placed them. This has caused more than a few issues for our installer, and a few failures in upgrade installs. It has been painful, and with the press of paying business we have been unable to find a solution that works consistently.

However, I have been seriously toying with letting the PGforMac installer fall into disuse and move all of the tools to the EnterpriseDB installation. With that becoming more or less the "official" Mac binary installation, it would seem that this project is fragmentation that is not required, particularly since that project uses more Mac standard paths. Before I make a decision like that, I would be quite interested in other users thoughts before I made a decision like that.

That said, we are trying to figure out ways to make this project a little more self supporting. The idea that keeps floating around the office is to build a commercial product front end for PostgreSQL and sell it. Honestly, I've been the most resistant to this because I want the DB and it's parts to be free. But this is something that we still have to discuss, and work out.

Issues, Issues, Issues

Tue, 07 Apr 2009 11:26:22 -0400

Well, the current installer has them. Well specifically one. On some machines the installation is failing, and it is failing on the Preference Pane. The errors are misleading and inconsistent, but they all seem to trace to a relocation bug in the Preference Pane. We are investigating, testing and fixing, but do not have a timeframe yet. All we can say for certain is that we know the issue, just not the fix.

8.3.7 Available Here

Sat, 04 Apr 2009 00:15:56 -0400

PostgreSQL 8.3.7 has been pushed to this download server, but has not yet been added to SourceForge. We will do that monday, assuming there are no crisis here.

Download the Unified Installer for 8.3.7.

Bad Timing

Tue, 31 Mar 2009 10:16:52 -0400

So PostgreSQL.org released 8.3.7 about the same time as my real job was entering a major crunch time to deal with a federally mandated change at all of our customers. 80 hour weeks + OSS side project == OSS side project slipping behind paying work.

Well do I understand that that is not what everyone wants to hear, but that's reality.

Fortunately, tomorrow is the deadline, and we are finishing delivery today (yay!). So tonight and tomorrow I will be able to run through the manual parts of the build and test process to get 8.3.7 packaged up. Tentatively, April 3 should be workable for a release.

Untitled Text

Tue, 31 Mar 2009 10:16:13 -0400

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum bibendum, ligula ut feugiat rutrum, mauris libero ultricies nulla, at hendrerit lectus dui bibendum metus. Phasellus quis nulla nec mauris sollicitudin ornare. Vivamus faucibus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Cras vulputate condimentum ipsum. Duis urna eros, commodo id, sagittis sed, sodales eu, ante. Etiam ante. Cras risus dolor, porta nec, adipiscing eu, scelerisque at, metus. Mauris nunc eros, porttitor nec, tincidunt ut, rutrum eget, massa. In facilisis nisi. Sed non lorem malesuada quam egestas bibendum. Quisque bibendum ullamcorper purus. Integer id diam vel elit adipiscing consectetuer. Phasellus vitae eros. Vivamus laoreet consectetuer tortor. In congue dignissim quam. Suspendisse nec purus vel velit ultricies bibendum.

More Preference Pane News

Tue, 17 Mar 2009 12:01:12 -0400

Obviously we are focused on getting the preference pane completed. Though this revision is not yet available, we now have the data view working for the pg_hba.conf file. If you look at the screenshot, it works pretty simply, though suggestions are welcomed :-).

The nitty gritty details are that behind the scenes we are directly updating the raw source from the data view. This means that changes made in the data view are immediately reflected in the source view. Due to those edits, you can review them before they are updated.

Also of note is that there is an issue in the current source editor that defaults to the update button on pressing enter for a new line. That bug has been addressed in the internal build so that the enter key does not map to update while editing the source.

Once this is vetted, we are going to update the 8.3.6 package with it and move on to the PostgreSQL.conf editor using the same model.

After that, it will be time to tackle the next bit.

The Query Tool as it exists is a fairly rough tool. For what it does, it is fine, but it really is not a good long term tool. We have toyed with several approaches at reworking the current code, but none of them really appeal. Originally we had envisioned a Mac like version of Microsoft's Enterprise Manager from it's SQL Server 7 product. Unfortunately, that is a paradigm that just doesn't translate well to the Mac user experience. Looking at other Mac specific database solutions, they all seem to oversimplify or have limited functionality.

There are some interesting options out there in the MySQL world (Querious and Sequel Pro), that are more akin to what we want. But they still seem to be missing functionality that we want to see. So with that in mind, we are starting to sketch out a new project to replace Query Tool. We have a long way to go, but after the preference pane, that's next, and it will embed all of the client tools into a single application, to reduce the clutter of the install and client toolset.

Released 8.3.6

Fri, 06 Mar 2009 16:41:11 -0500

While not quite to where I want it to be, I do not think we can hang onto the release much longer. So today, we are publishing the current 8.3.6 installer and tools. Below are the release notes

The preference pane continues to be the focus of the GUI work. Building something that makes it easy to manage a PostgreSQL installation is still probably the most important task on the list, so we will continue making previews available through the blog.

** Release Notes **

03-05-2009

* Heavily modified installer to address issues with file creation and ownership changes during initial setup. This should address the bulk of the installation failures.

* Updated Preference Panel to include new functionality.

* Readded uninstall script

* Readded Automator Actions

* Preference Pane now allows editing

* Preference Pane now allows control over auto start

Known Issues

* Change Data Directory does not fully work (does not perform and initdb on the new directory)

* None of the Data Views in the Preference Pane work, only Source Views.

* The installer does NOT stop a currently running instance of PostgreSQL, and will fail the install if one is running.

* If the installer fails during the first run, please capture the error log before running it again, as it will most likely succeed on the second run.

Closing in on Complete

Tue, 03 Mar 2009 11:09:30 -0500

Last night, one of the last major hurdles to a new release was completed. The preference pane and startup scripts now work to honor the data directory and startup options. These changes also resolve a couple of long standing issues with the startup item itself.

With these items done, we are looking at packaging 8.3.6 with the current work in progress of the Preference Pane late this week for a Monday release of the 8.3.6 revision.

Also, we have added a search feature to the website to make it easier to navigate and find old articles.

Preference Pane - Preview 2

Wed, 25 Feb 2009 16:29:20 -0500

Alrighty folks, while stilll very much incomplete, the preference pane is moving along. Today, we are making the second preview of the preference pane. This version allows editing of both the postgresql.conf and the pg_hba.conf files from within the preference pane. It has also stubbed in the support for auto-start and data directory paths, though both will require the updated startupitem which is still being tested.

What isn't addressed here is that cosmetically, this thing is still a mess. The code is functional, but not pretty. The Data views are completely broken. None of this is surprising, it is a work in progress, but it is usable for what it needs to be. That is the start, and the next step is clean up and polish.

With that in mind, the 8.3.6 installer has been tested a little, and we are leaning towards releasing it with the knowledge that it will fail an instance of PostgreSQL is already running.

Either way, you can download a copy of the preference pane to play with from here. We would love to hear your thoughts on it as we start down the path of cleaning it up for a finished product.

Edited because I screwed up the download link, the corrected link is now in place

Preference Panel Previews

Fri, 20 Feb 2009 13:30:55 -0500

It has been a couple of weeks since I've had a chance to talk about the preference panel. We've made some changes and enhancements, and I wanted to give a quick

visual tour.

In this first screenshot, you should notice that we have removed the icons and gone to buttons. In addition, they are disabled unless the panel is unlocked.

Now in this second shot, the two changes are that with the panel unlocked, the buttons are enabled. Also, the lock now provides visual feedback that it has been unlocked.

While not major changes, these provide better usability and a more consistant user experience. I think it could go a bit further though.

Part of this effort also ties into another bit. The settings that the Startup Item uses for data path and deciding if it should autostart or not are now stored in a preference file. Meaning that these values can be set from the command line using the defaults write command.

This third screenshot displays the source edit view of the Network Configuration panel. For the first release, this is all that will work for updating the files. It is just a basic text editor, and when the user makes changes and presses 'Update' the panel will automatically put those changes in place. It will also attempt to do a server reload to pick up the changes. If there is a problem, the intent is that an alert will show up in the panel, but capturing the problems may be a little tricky, so I don't know if that will be ready for the initial release.

Last, we have the 'User Friendly' edit mode. This mode won't initially be available other than as a pretty 'here is what is coming'.

As you can see, it is intended to make it trivial to manage the entries in the HBA configuration without having to make all the entries in the text file. Other than that, it works the same as the source view, which is in fact that output process. Making changes here, will alter the source view, and the source view is the one that will be written and updated.

The PostgreSQL configuration panel will work the same way, though it is still a couple of days away from usable. We are trying hard to get this wrapped up for the 8.3.6 publish before the end of the month.

I hate this time of year...

Mon, 16 Feb 2009 10:33:46 -0500

For those of you that don't know, I and the guy that does most of my testing, both live in Atlanta, GA. This time of year is the time when I invariably get sick because of our wonky weather. This year is no exception. Since midday Thursday, I have been generally useless with a sever sinus cold that has kept me from being able to focus on a computer screen. Today is the first time I've been able to really focus.

Because of that, I am posting this first, then trying to wrap up the installer testing. I haven't gotten much feedback on the 8.3.6 revision, so at this point, we are assuming that there are no major issues with it beyond the lack of an upgrade halt if PostgreSQL is already running.

With that in mind, the next couple of days will be dedicated to wrapping up some changes to the Preference Pane and the editing of the config files. With those complete, we will bundle a new disk image and hope to publish this week. Hopefully, I'm done being sick this year, but the weather is doing it's usual. It was 75 last Sunday, it's 51 today, and will be in the 30's by the end of the week.

Initial Testing 8.3.6 and Updated Installer

Wed, 11 Feb 2009 19:21:07 -0500

Alright, hot on the heels of the prior test of the installer, here we go with another. There remains an issue where it will not stop if there is an installation still running. That will be addressed in another test release in the coming day. This is specifically to address installation issues and to include the new 8.3.6 release. We are working furiously to get a few other bits of code finished for a full publish of the updated installer and package for Tuesday of next week, so any and all feedback on this and the next test release are much desired.

Get it HERE

Testing ?

Wed, 04 Feb 2009 23:22:42 -0500

Alright, at this point, the installer appears to work, but we need more people to run it. This doesn't deal with newer versions, it's just the installer we are looking for some extra testing on. Make sure that it leaves a running PostgreSQL server at the end. If you don't, let us know and send us a log of the installer.

Get it HERE.

Installer Testing Takes Forever

Wed, 04 Feb 2009 10:55:46 -0500

Sorry this is taking so long, but it takes forever to test the installer changes. Build the installer, test it, clean it off, rinse repeat. That doesn't even bring the change/tweak time into the equation. At this point all I know is that we are close. We have one machine that continues to give us an occasional issue, and that is the upgrade on PowerPC 10.4.9 installation from 8.3.x to current. The database is not initializing properly.

We will continue to work on that and will continue to post as we know more.

Installer Update

Wed, 21 Jan 2009 10:40:37 -0500

Well what we thought was the fix for the installer has issues as well. At issue is that prior to Mac OS X 10.4, the niutils command line for managing users had support for a forced reload after you made changes. As niutil was replaced with the new dscl command, there is no forced reload. The problem is timing.

In the installation scripts, the core installation puts all the base files in place. Once they are in place, there are two additional steps that have to happen. The postgres user and group have to be created, then as that postgres user, initdb has to be run.

Originally, these steps all happened in one script, the postflight script that was the last thing that the installer ran. Starting with 10.4, this had to be reengineered into two scripts, postflight, and postinstall/postupgrade. In most cases, this seems to work, but there remain instances where the installation fails because when the initdb is called, the user or group is not yet found. As a part of this, the log file permissions would also fail. The net result, the installation would work, but it wouldn't start without manual intervention after the install.

Identifying the problem was step one. Step two has been fixing it. The first couple of attempts have been to rework the sequence of events. This seems to have reduced the number of instances of the issue, but not eliminated them. Since then, we introduced an artificial delay into the scripts to attempt to mitigate the problem. That causes some problems with the installer itself. With all of that done, things still aren't quite where we want them, so we are working from another angle. Now we are moving some of the post processing into preprocessing in the packaging. The Log and data directories will be created as part of the archive rather than scripted. This will leave just the permissions and the initdb. In order to eliminate the timing issue, we are moving the user and group creation to before the archive is installed. By doing this, the file copy should create enough of a delay that by the time the initdb is run, everything should be reflected in the environment.

Now I will be on the road until next tuesday, so I don't expect to have a release published until next week, but I did want to take a few minutes to let you all know where things stand.

Also of note, per the comments and emails about he HBA configuration tool, we have reworked it into a single list and will be making an early adopter release in the coming week to get some other hands on it for both testing and suggestions.

Getting Started with PGSQLKit

Mon, 12 Jan 2009 19:59:01 -0500

Published today, this is the long promised but always pushed to the back burner, How to Get Started with PGSQLKit. This is the first of what will eventually be a short ebook about using the PGSQLKit framework, but this is the first article. Critiques and comments are welcomed.

Download and read the PDF: Getting Started with PGSQLKit

Added Article for Manually Fixing Installation Error

Mon, 12 Jan 2009 15:05:19 -0500

Since there are still some failures in the installer, we have posted an article about addressing them when they occur. It can be found under 'Server" and is linked here.

Network Configuration Tool

Fri, 09 Jan 2009 21:24:29 -0500

Well the installer work is progressing, but in parallel so is the work on the Network Configuration Tool. Attached here, is a screenshot of it in it's unsexy rough "Work In Progress" dress. While we get all the nitty gritty functionality working, this is the rough layout. What you see here is the three groups of connections. Each has it's own section. Double clicking on a record edits the record, while the + and - buttons will add or remove a record. The third button (currently just a place holder) edits the currently selected record.

When this opens, it requires a system administrator password, in order to read the currently configured PostgreSQL file. At present, it is hard coded to the /Library/PostgreSQL8/Data path, but will read the StartupItem's path before release. Using that file, it creates a temporary backup /var/tmp/, it parses and displays the data on screen. Once you make changes, you will have the option to save backup, discard and exit, or save. Saving the file does two things. First, it writes the file, and then it notifies the PostgreSQL instance to reload the pg_hba.conf file via the StartupItem.

There is currently no way to read the results of the reload, so it is possible that if you have a bad file, it may fail the reload. Obviously we want to prevent this from happening so the next phase of development is all about the UI and validation before the file ever gets read.

That is where things get tricky. One of the questions is should the system try to obtain a database list automatically? can it assume the postgres user is available and Trust is enabled? by default it would be, but once security is tightened up, it may not. That would then require a second login. While not impossible, it presents a bit of a user interface dilemma. Should the whole process move to a wizard based paradigm? Should it just stack login dialogs? Neither are particularly appealing.

Opinions are welcomed, but we are moving forward so make em quick!

Good to be back to work...

Wed, 07 Jan 2009 12:33:07 -0500

The holidays are always nice, but the chaotic schedules during the holidays are wearing. It really shows on projects like this which are primarily spare time projects. In the midst of the chaos, I personally got little to nothing accomplished on PostgreSQL related projects during the last 3 weeks, and since I've had little contact with the other contributors, I assume that they had the same issues.

So, with the start of the new year, it is time to get caught up. First on the agenda is getting the installer rebuilt and released with the new fixes in place. Hopefully, that installer will contain the rough draft of the pg_hba.conf editor. At this point, that editor loads the files and saves them, but does not yet allow modifications. It is very much a rough draft, with an ugly UI, but for the purpose of initial design and testing, it will work.

This also means focusing on building this part of the business again. We started this process back before the holidays, though not much was said about it. First and foremost, in order for this project to really continue to grow, we need to treat this project as more of a business venture than a hobby. With that in mind, we started working on a plan to bring this project into our daily routine. Eating our own dogfood if you will. While we've always used bits and pieces, we are very comfortable at the command line and so we would use those tools if the GUI didn't get it done. Because of that, sometimes issues in the GUI tools got ignored.

Part of the plan is to not use the command line tools internally. If we can't do it in the GUI's, we need to fix the GUI's. That should help quite a bit. It will require some changes for us, but that's the way it has to be.

The other bit of this is that as we migrate to the new Druware website for our projects, we are looking into bringing the current PostgreSQL for Mac resources in house, specifically the discussion and issue tracking venues. That will probably be March or April at the absolute earliest.

So here is the tentative plan for Q1. Jan 15 should see the 8.3.5b release to address current issues. March 1 should see the preference pane including both the .conf editors and password tool, and May 1 seeing the next revision of PostgreSQL released including a revamped Query Tool (to be renamed PostgreSQL Data Studio).

Found!

Mon, 15 Dec 2008 10:43:36 -0500

Well the problem with the installer has now been found. Fixing it is going to require a couple of days, not so much because of the code, but the testing, and the holidays.

I'll keep everyone posted, but this is a good step, sorry that it's taken so long to isolate the problem though.

Still Sifting through the Install Issues

Wed, 10 Dec 2008 11:12:16 -0500

Just in case you thought this was forgotten, it's not. The issue is that we are still sifting through the problems that occur on some machines. The core of the problem is that the problem is not the same on all machines. There appear to be two different core issues. The first is that during some installations the initdb stage fails with no error, causing the installer to fail. This one is the easier of the two to trace and we think we've finally isolated the cause. The other however, is proving much more elusive.

In some installs the PostgreSQL8.log file is a a symlink, and the permissions on the link are getting set incorrectly. What is unusual, is that it only breaks in some installs. Worse, it is not isolated to update installs or new installs.

So we continue to work to isolate that before we build a new package.

Uninstall 8.3.5

Tue, 25 Nov 2008 12:03:06 -0500

In order to get the uninstaller out to the folks that need it now, we've gone ahead and posted the script required here. You can download the shell script or you can cut copy paste from the below it you are more comfortable with that:

#!/bin/sh

# clean up the previous installation so we can test it again.

echo

echo \# This script will attempt to remove all vestiges of a PostgreSQL8 installation

echo \# -----------------------------------------------------------------------------

echo \#

# make sure that we are running as root

x=`whoami | grep root`

if (! test -n "$x") then

	echo \# You must be root \(sudo\) to have sufficient rights to remove the

	echo \# folders and files that need to be removed.

	exit 0

fi

#set -e

echo \# User: $x

# make sure the database is shutdown

echo \# Stopping the Database

/Library/StartupItems/PostgreSQL/PostgreSQL stop

echo \#       ...done

# remove the user and group from the netinfo database

echo \# Removing NetInfo entries

PG_UID=`/usr/bin/dscl . -read /users/postgres | grep "^UniqueID:.[0-9]" | sed 's/.*: //' | sed 's/ //'`

# User exists

if test $PG_UID; then

	sudo /usr/bin/dscl . -delete /users/postgres

	echo \#        ...Deleted Postgres User: $PG_UID

fi

PG_GID=`/usr/bin/dscl . -read /groups/postgres | grep "^PrimaryGroupID:.[0-9]" | sed 's/.*: //' | sed 's/ //'`

# Group Exist, destroy it

if test $PG_GID; then

	sudo /usr/bin/dscl . -delete /groups/postgres

	echo \#        ...Deleted Postgres Group: $PG_GID

fi

echo \#       ...done

# remove the log files

echo \# Removing Logs \& Receipts

sudo rm -f /Library/Logs/PostgreSQL8.log

sudo rm -rf /Library/Receipts/backupDatabase.pkg

sudo rm -rf /Library/Receipts/cleanInstallation.pkg

sudo rm -rf /Library/Receipts/createDatabase.pkg

sudo rm -rf /Library/Receipts/createUser.pkg

sudo rm -rf /Library/Receipts/pgsqlkit.pkg

sudo rm -rf /Library/Receipts/postgresql.pkg

sudo rm -rf /Library/Receipts/postgresql8.pkg

sudo rm -rf /Library/Receipts/postgresql83603jdbc3.pkg

sudo rm -rf /Library/Receipts/postgresqlServer.pkg

sudo rm -rf /Library/Receipts/queryToolForPostgres.pkg

sudo rm -rf /Library/Receipts/uninstallPostgresqlServer.pkg

echo \#       ...done

# remove the directories

echo \# Removing Files and Folders

sudo rm -rf /Library/PostgreSQL8

sudo rm -rf /Library/StartupItems/PostgreSQL

sudo rm -rf /Library/PreferencePanes/PostgreSQL\ Server.prefPane

sudo rm -rf /Applications/PostgreSQL

echo \#       ...done

echo \#

echo \# -----------------------------------------------------------------------------

echo \# PostgreSQL8 has been removed from the system.

8.3.5 Details

Thu, 20 Nov 2008 10:09:57 -0500

So there are 3 significant issues with the current 8.3.5 release.

* README is from version 8.2.5, not 8.3.5.

* Uninstall.sh is not being installed as it should.

* Post Upgrade Script is failing to set the permissions on the Data folder in some instances

All of these need to be addressed, so the plan is to resolve them and get a new package published this weekend. The README is easy, and already in the new disk image. The Uninstall is also fairly easy, but there is a bug in the uninstall that needs to be addressed. The current uninstall fails to remove the receipts from the /Library/Receipts/ folder.

The post upgrade problem is proving to be elusive. I've only found one machine that I can reproduce the issue on, so testing and restoring to a state that I can retest on takes time. At this point, I know *what* causes the issue, but I don't have a firm handle on how to fix it reliably. Having put a couple of hours into it today, I am taking the afternoon away to let the subconscious gnaw on the problem. I figure I'll come up with a solution I like when I'm doing my yoga, that's how it usually happens.

Problems with 8.3.5

Tue, 18 Nov 2008 10:15:04 -0500

So far we are aware of two issues in the just released 8.3.5 packages. First, the README is the wrong PDF. Apparently I copied the one from the wrong disk when I was putting everything together and failed to catch it.

The second issue is actually more of a concern though. I now have two reports of failed installed during the post install stage. I have been unable to reproduce the problem in any of my environments, so I am now hoping that one of you can provide more details about the issue, perhaps an installer log or two.

In the meantime, I am working on a new disc image to address these issues, and I hope to have it ready before the holiday next week.

8.3.5 Incoming

Tue, 11 Nov 2008 16:11:41 -0500

Alright, 8.3.5 is built and published. This release does away with the Service Manager and adopts the Preference Pane. It is now installed as part of the server. All of the other tools in the package have been rebuilt against the 8.3.5 libraries. Beyond that, the changes for this release are pretty minor.

Create User has been migrated to PGSQLKit and no longer uses pgCocoaDB. The Automator Actions are not yet available, the Dynamic Query action is still flaking out on Leopard as a result of ripping out the registration code that was in there for it to be sold as shareware. If there is not a PostgreSQL 8.3.6 before January 1, there will most likely be a new PostgreSQL for Mac release to include them before then.

I should warn everyone that we are working on some rearranging of the website to make things easier to navigate. This may result in some broken links, if you find one, please contact us.

One of the things you may notice is that there is now a 'Documentation' menu on the right of every page. This is certainly incomplete at this point, but is being updated as we get time to expand the documentation.

Preference Pane, Query Tool and StartupItem

Tue, 11 Nov 2008 16:10:16 -0500

It's been a busy week so far, so let's jump right in.

First, it looks like the version of the Query Tool that got packaged in the unified installer disk image is missing pgCocoaDB. If you have an older installation installed, you probably aren't seeing any problems because they installed pgCocoaDB into the /Library/Frameworks folder. On new installs however, it fails to launch. Until we can get the disk image updated, we are making the fixed Query Tool available here.

Second, if you are monitoring SVN, you saw a change hit the StartupItem in prep for the Service Manager replacement Preference Pane. The changes are in three parts. Part One is a change to allow easy configuration of the Data folder. Part Two is a change to make it possible to enable the 'Auto-Start Service' check box, and last but not least is the ability to easily move the Log file. These are not major changes, but they do have to be made for the longer term good.

Third, we have a build of the the Preference Pane that replaces the Startup Manager. This is just a first pass, a whole lot of functionality is completely disconnected right now, but in the OSS spirit of release early, release often, we wanted to go ahead and get an early sneak peek out there. So it is also available today (expand it, run it to install it). Several things will change about how it is implemented, but for now, we need feedback on things as we enable them. This initial release, starts, stops and restarts the server. That's it. We should have the full Lock / Unlock security enabled in the next code drop, which sets the stage for enabling the Access Control tool to manage the pg_hba.conf.

Disclosure

Mon, 03 Nov 2008 11:41:11 -0500

Alright, it's been a few months since I updated the spreadsheet about the financial side of PostgreSQL for Mac, so I got that done while watching football Sunday. Nothing really surprising, page views and ad clicks are well down from the records highs or March and April (about half). For the year to date, have raised $353.52 in funding, which covers our annual hosting billl ($120 for the Xserve), and puts a little bit of money into the artwork pool. Needless to say, we are a long way from moving to a dedicated Xserve for the server, and even further away from any of us making this a full-time job. (see the full pdf)

Some of that stems from the fact that we really have not aggressively marketed the project, nor have we aggressively marketed support contracts for PostgreSQL on the Mac. First off, I'd like to start solving the former, by doing my part, so you'll see that we have updated the references on MacUpdate and VersionTracker. We are also now setting up a page of Marketing Materials, starting with a new 'Mac Ready' button you can display on your own weblogs and websites. Feel free to download the image and post it anywhere you wish. The other thing that is being done on this front is to go through the website and tweak it for better search engine findings.

These things should help our visibility, but it doesn't help on the revenue side.

I really want to see us get at least one developer working on PostgreSQL for Mac for at least 2 days a week, preferably full-time. In order to do that, we are going to have to push a couple of support contracts. The problem is finding a fair and balanced structure. Tentatively, we are looking at a $600 / year / per server service contract with Druware that is a mail/phone 8-6 x 5 support system for priority handling of issues and problems. In addition, it looks like there is a need for some consulting, so we are also looking at a $100 / hour consulting offer that gets you one of the core team to work with you on design and implementation consulting. Neither are set up in the system yet, as we are still researching, but we see Sun (who has the resources to staff a 24x7 support center) is offering PostgreSQL support on a 12hour x 5 day contract for $1500 per server. We don't have the resources to match a 4 hour turn around and 12 hour coverage, so we are looking at 10 hours a day of coverage with 24 hour turnaround.

At those rates, we would need 100 servers under contract to meet our initial goal. While attainable, realistically, I think the overhead will be such that 200 would be a real target to support a full-time person, and then we could at an additional full time person for each 150 servers under contract. Before we move forward with this, I am very curious as to the communities thoughts, too high? too low? not enough service?

8.3.4 on SourceForge, new SVN commits

Thu, 30 Oct 2008 14:50:39 -0400

There is a lot of information in this post, so I apologize about the length in advance. As should be obvious from the previous post and the announcements hitting the wires, This morning saw PostgreSQL for Mac 8.3.4 hitting the SourceForge servers. This release marks an interesting milestone. We have now been doing PostgreSQL for Mac for over 3.5 years, however our first real release came 3 years ago. During that time we have seen a bunch of changes, some good, some bad, but the important thing is that we are more motivated today to PostgreSQL and this project than we have ever been.

Yes, there was some thought about abandoning the project with the apparent blessing of the Mac distribution from EnterpriseDB by the PostgreSQL.org website. There are other distributions for the Mac as well, and we questioned our value in the space. The more we worked with the alternatives, the more convinced we are that not only are we relevant, but that in many ways, our goals are so different from the other Mac distributions, that the long term is looking pretty good.

I guess the point I'm trying to make on behalf of the team is that after 3 years, we are looking forward to another 5-10 of PostgreSQL work.

That said, as of last night, we committed the 8.3.4 work to SVN as revision 205. Now it is time to move forward, and the forward starts today.

Everything going into SVN from now until 8.3.5 is released ( I figure 4-8 weeks from now ) is being tagged as 8.3.5. This is important, because there is a bunch of stuff going on in SVN right now.

Druware's Automator Actions are now a part of the project and are now in SVN on SourceForge. These are becoming part of the main distribution. All of the code is checked in and ready to build. Also added is the rough code from a month old code drop of the Preference Pane (largely because the laptop the main code is on is being rebuilt right now).

These changes also mean some other changes in SVN. In the next release, the Service Manager is going to be retired. It will be replaced by the preference pane. This *also* means that the StartupItem is going to evolve a little bit. For a while, we looked at switching to Launchd, but there remain some limitations to launchd that leave the StartupItem as the better option. So the StartupItem is getting some changes to better work with the PreferencePane to enable altering the Data directory, and dealing with the configuration files stored there. Also being changed is the ability to enable and disable the startup process from within the PreferencePane.

All of these changes are intended to make the basic installation and management that much easier.

But that is not the end of what is changing. Query Tool will remain largely unmodified for a little while. We had a long discussion and concluded that the concepts intended for the PostgreSQL Data Studio from Druware really needed to be made part of this project to give it the complete feel we wanted, so that product is also moving here. As a project it is a large undertaking, and we won't be able to focus on it until we get the Preference Pane completed.

Sorry for the deluge of posts the past couple of days, but I expect the flood to continue while we move forward with some projects that had been kinda idle while we worked on some other things.

Here today, SourceForge tomorrow

Wed, 29 Oct 2008 22:09:28 -0400

Alright, the initial release of 8.3.4 is now published to the PostgreSQL for Mac website, the download links are on the right and are ready to go. I am holding the upload to SourceForge.net until midday tomorrow, simply because this is quicker. This is both the 'Unified' and the 'Client Tools' updated to 8.3.4. That is the biggest change, though there are some little ones here and there, nothing is really that big a deal. The Automator Actions are not packaged in the release, they are being moved to a separate download as there has been no communication that they are being used in any way, and by isolating them out, we make it easier to download just the Actions for those that want them.

Also, the we've started putting together the sanitized versions of our Automator build workflows. They are incomplete, as we have to strip out passwords and some other environment specific details, but the end goal is to have a set of workflows that anyone could plug in their passwords and have do the entire set of builds without too much hassle. Those stubs are now in SVN.

Speaking of SVN, we have been doing some clean up, and the Installers folder has been paired down to what we are still using. The pgGUID project has been 86'd, as it has been dead for 2+ years as well. Create Database has been moved to PGSQLKit and is no longer dependant upon pgCocoaDB. Create User will be done shortly, however, Query Tool will likely remain on pgCocoaDB for the short term. There is another project that will likely replace Query Tool in the long term, but it is still in the early UI design stages and will not be under any serious development until the Preference Panel is closer to completion.

Building tools, distribution and site changes

Wed, 29 Oct 2008 12:36:45 -0400

With initial tests of the new build looking quite good, the rest of the build up is going on now. There were some concerns with an initial test, but that turned out to be a poorly designed testcase. In case you were wondering how we do most of our testing of the databases, most of them are Automator Workflows that tests queries using each of the supported languages.

This means that sometime today we should be publishing the full distribution as we have in the past. For this dist, there will be no 'new' features to the tools. Those are just not ready for release yet, but everything will be rebuilt against the 8.3.4 libraries.

So what is new. First, most of our PG4Mac development time over the last several months has been focused on the build process or documentation. Documentation is boring, not fun work, but in many ways, it is the most important bit of what we do.

Today, we have a new article on the site that should be of great benefit for many people. This should help ease the pain of configuring the various configuration files. HowTo: Edit PostgreSQL Configuration Files is an article on how to use Finder to set up permissions to allow you to edit and manage the configuration files without having to use Terminal and VIM. This how we work with these files, since we are mostly GUI users, and generally use either BBEdit or Xcode for editing them.

The other big document project should be done in the next couple of days, and that is a Getting Started with PGSQLKit document that will walk through building a simple application using the PGSQLKit. Along with that is the ongoing project of documenting the PGSQLKit classes. With the fantastic work from new contributor David G, we've been able to get quite a bit of clean up work done in the framework, which has in turn allowed the documentation process to really start moving forward.

Is it hot in here?

Tue, 28 Oct 2008 16:28:10 -0400

Alright, so we now have a working build and installer. We do not use text search internally, so it may have issues, but as far as we can tell it works. In the interests of getting a few external folks to test the build, we have assembled a bare bones installer (server, service manager, startup item, jdbc adaptor) for testing as an interim build while we finish up packaging the rest of the goodies.

The Interim build is available here.

This is PostgreSQL 8.3.4 built in 4 flavors in one. What we have is a 10.4.x build for supporting the 32bit platforms (PowerPC G3+ and i386), while the 64bit builds are 10.5.x only. As per usual, this is with bonjour, tcl, perl, plpgsql and now full text search. In addition, it *should* have all of the various shared libraries in all four flavors so that your favorite tools should just work, including the 64bit Apache modules.

From a techie standpoint, if you need to compile something that is dynamically linked to PostgreSQL, have it include the PostgreSQL path as /Library/PostgreSQL8/ ( for example: gem install postgres -- --with-pgsql-dir=/Library/PostgreSQL8 ). If you want static linkage, wait for a couple of hours and we'll have the /opt/local/ developer's package packaged up. Bear in mind, the /opt/local folder is solely for creating tools statically linked to postgresql, or for using statically linked binaries from the PostgreSQL package (we do this for 'Backup Database', and PGSQLKit.framework). It is NOT a usable installation, it is just there for development purposes.

Last but not least, thanks again for all the support getting through this. Work has been hectic, and getting all the bits and pieces reassembled has not been fun, your words of encouragement have counted for much.

There should be a full package later tonight or tomorrow.

Ohhhh so close...

Mon, 27 Oct 2008 13:29:41 -0400

Over the weekend we got a working build of the server for all 4 platforms. The problem, we have one broken tool in the in regression testing, ipcclean is built incorrectly on PowerPC 32 bit. That should be resolved this afternoon, allowing us to publish 8.3.4.

Status?

Mon, 20 Oct 2008 10:35:45 -0400

So here is where things stand.

X86 64 bit is built and running on 10.5.

PowerPC 64 bit is built and running on 10.5

PowerPC 32 bit is built and running on 10.4

i386 32 bit is built and running on 10.5, needs 10.4.

No matter what I've tried this weekend, that last one will not cross compile with a working plperl when either built cross compiled from PowerPC under 10.4 or from Intel under 10.5. So where does that leave me (other than scratching my head)? I've pulled one of the MacBooks that the kids were using to install 10.4 on, and test the build there. This is kinda the brute force approach, but at this point, I am sick of this looming, and my frustration with cross compiling dealing with Perl has reached a point where I am just generally annoyed and grumpy about :). Assuming this works as expected, I'll be on the hunt for a first generation Intel Mini to install, configure to build latest every friday, and put in a closet somewhere.

Beyond that, while builds have been running I started on the first 'tutorial' for building a PGSQLKit application. I hope to have it completed this week. Assuming that works out well, I think I am going to attempt to build a screencast of the tutorial as well.

Decisions

Fri, 17 Oct 2008 14:25:56 -0400

Alright, so here is the issue. We have all four platforms built and they pass tests. The problem, right now, they are all built for 10.5. Cross-compiling to target 10.4 is continuing to fail. Soooo..

What does the community think? drop support for 10.4, or keep fighting? (FWIW, it's failing on the usage of ar in libplperl and libpgport).

Post a comment and let us know your thoughts.

8.3.4 Progress

Fri, 17 Oct 2008 11:38:28 -0400

Alright, so last night we got 8.3.4 built and running on all 4 platforms. This was a huge task. Now that it is built and seems to be running through the tests (including resolving a long outstanding issue with tsearch / full text searching), we are working on building up the tools and getting the packaging all reassembled.

Expect a release later today.

PLPerl is a Pain in the Butt

Wed, 08 Oct 2008 11:43:53 -0400

Alright, I understand that PLPerl is popular, but as a package builder, it is a royal pain. The delay on getting 8.3.4 out the door is that PLPerl refuse to refuses to use the CFLAGS passed into it for architecture. This make compiling the 64 bit versions difficult (at best). This has been a problem for a while, but the prior builds glossed over it by not including the 64 bit versions in the universal binary. That is causing issues for some users. So, here we are. fighting with it again. I'll have more details later.

Release Progress & Comments

Mon, 29 Sep 2008 11:12:48 -0400

So the PowerPC build went without issue, but we are having some performance issues with the Universal binary on the x86 box. Until that is resolved, I won't be able to package the binary. I started looking into the details of the problem this morning, and I suspect it may not be PostgreSQL but a hardware issue on the test machine, so I am replacing the Mac Mini that is the test machine with my old MacBook Pro in the test environment now. If it passes all of the tests, I will package and upload later today.

So next, about comments. I'm not sure how I managed to turn them off, but I did. They have now been reenabled on the blog posts, and should stay that way. Sorry about the goof on that.

Current Work

Fri, 26 Sep 2008 10:18:29 -0400

During the last couple of months, we've had a couple of new contributors working their way into the code, and with that, PGSQLKit is maturing rather nicely. For me, this is a nice benefit, as it has freed me up to work on some of the other things that really need to be done on the project in general. One of those projects is to take the old Service Manager and turn it into something more appropriate for the Mac.

Initially, the plan was to build this into the Apple Server Admin tools, but as near as I can tell, there is no interface for doing so. Because of that, I have chosen to build it as a preference pane in System Preferences. What you see here is the first running prototype of the panel. There remains a ton of work before it is useful, but it is a start, and it will be my primary focus for the project for the coming months.

It will not be available prior to 8.3.4 however.

8.3.4 is building on the server right now, and we should have it testing shortly. I have a good expectation that it will be available by Monday.

Where is 8.3.3?

Wed, 17 Sep 2008 16:22:31 -0400

Obviously, not on the servers. Why is very simple. Paying Customers > OSS projects. The fun thing about this though, is that the paying customers in this case, come in the form of two customers both wanting some improvements and enhancements to another project that depends upon another OSS project. The net result, ODBCKit has been getting the love the last couple of weeks while PostgreSQL for Mac has been pushed off. For those interested, the ODBCKit changes where published this afternoon over at Druware.com as well as SourceForge. Get it while it's hot! :-)

This isn't an entirely bad deal though. One of our new contributors, David, has been doing some much needed cleanup and enhancement to the PGSQLKit while I've been away. That means good things for the next publish, which will hopefully be soon.

Hopefully, the delay will also give me time to finish the initial work on the new Preference Pane version of the PostgreSQL Service Manager. Now wouldn't that be nice?

Projects?

Thu, 11 Sep 2008 14:56:14 -0400

We are putting together a page of projects that are using PostgreSQL for Mac or the PGSQLKit and are looking for submissions. If you are working on a project that makes use of either, let us know and we will get you added to the list.

With Thanks

Thu, 04 Sep 2008 21:36:51 -0400

Thanks to David, I have recovered the articles from the history, and will be adding the back to the archives as time permits. Mostly while I wait on things to build for testing.

Not Dead...

Thu, 04 Sep 2008 11:30:11 -0400

So no, the project isn't dead, just buried a little. I guess a little background is in order. I work primarily on a laptop. Back in April, my laptop lost a hard drive. Normally this wouldn't be an issue, but I had made the mistake of using a Maxtor External hard disk as my primary backup device using Time Machine since January 1. This proved to be a very big mistake, as when I went to restore from said back up, the Maxtor proved once again why I shouldn't trust them, it tanked as well. Taking with it quite a bit of my work and all of the website updated between January and April. Nothing else was effected, as it was all in SVN, just the website (which is also now in SVN).

So in the process of rebuilding, things around here have been left largely to languish. Now that I have more or less gotten caught up, that is now changing.

First, for a while, I had considered pulling the PostgreSQL for Mac website back into my business website to make management and updating easier. After a lot of thought and consideration, I concluded that it simply did not make sense in the long run. With the decision made, the next step was to decide what to do about the site. I have elected to adopt a new visual theme ( Smooth Blue from Blueball Designs ), and to archive off the news prior to January without recovering the news between January and April.

That is what you see here.

Next, it has been brought to my attention that there is not an easy way to contact me directly from the website. Uh, oops? :), there is now a contact me form on the top menu to facilitate contacting me.

Last, at least for the moment, is news regarding 8.3.3. Initially, I was going to stop doing full installer builds, as PostgreSQL.org seemed to be favoring the EnterpriseDB Mac installer, but after using it an installing it, I feel that there is a place for both. I still feel that the Mac market requires more than just an installer to the same old Unix command line interface. So, I am working on getting a new build up and running. I suspect it will be the weekend before I have something ready to release. In addition, despite trying to generate interest in making a general API to manage the configuration issues in PostgreSQL I cannot seem to get any response other than if the command line is too hard for you, go elsewhere, I am going to make a go at making something work for the Mac users that want a better interface. That will not be an immediate impact, but will be seen in the not to distant future.

It is a pretty big project, but I think from an impact to Mac users, it is among the most important to tackle next, as many of us, even those that are comfortable doing so, don't like using the command line and vi to modify configuration files. The limitation is that for this initial pass, these are things that will only work on the server, you won't be able to run them on the client side (except to edit configuration files for a local copy of PostgreSQL for local testing prior to moving them to a production server perhaps).

It looks like we have arrived

Thu, 28 Feb 2008 10:42:01 -0500

Alright, I'm going to do this (probably not a good choice, time will tell). Anyways, I am posting this from I-75. My wife is driving and we are headed to a gymnastics event in Tampa, FL. Why am I posting this? well, after many hours and much pain, we have an installer that has worked on all three Mac's I have with me (PowerPC 10.4, Intel 10.4 and Intel 10.5), and having delayed this so long, I don't want to delay it any further.

I am not however posting this to SourceForget.net until tonight or tomorrow, assuming there aren't any glaring errors in the package that I have overlooked in my stress to get this out the door.

So, without further ado, the builds are posted. As usual, the Unified installer is a DMG that contains everything. If you download that, there is nothing else that you should need to download from here. The Client Tools download is primarily for use if you have a PostgreSQL server already installed and just need to access and manage it.

Remember, this is not an incremental revision, so you need to back up and delete your current /Library/PostgreSQL8 folder before installing so you get a proper database. Personally, I make by backup first, then in terminal use the command

sudo mv /Library/PostgreSQL8 /Library/PostgreSQL8.2.5_BACKUP

Then do my install to make sure that I have a copy I can revert to if I foul things up.

Good luck, and if there are issues, email or bug reports at SourceForge are the best way. Needless to say, response times will be spotty while I'm on the road until Monday.

Many thanks to Matt, Ed, the gang on #macsb and #postgresql for helping me through some of the hurdles getting this release up, running and out the door.

So Close

Tue, 26 Feb 2008 17:50:20 -0500

Well, we are getting close. As of now, we have an installer that works on the second run through. The first run fails if the the Postgres user and group do not preexist. We will work on this tonight, and hopefully have a fully functional installer for posting tonight or in the morning.

Not a happy camper

Mon, 25 Feb 2008 11:14:39 -0500

So after a long and grumpy weekend, we are still without a PostgreSQL 8.3 release. The problem at this point is the installer. I had transitioned most of the machines in the office over to Leopard back in January, and this was the first full release we tried to do under Leopard, and the problems we've had in the process have been really painful.

I've documented most of it here, but now we are into the final stages, the packaging and the results have been nothing less than a spectacular failure. The new Package Manager tools in Xcode 3 & Leopard have been a major hassle. There has always been a problem with the post install scripts that set up the database the first time on some machines. Well the good news is that that problem now effects all Leopard machines, so we can fix it. Unfortunately, debugging the scripts is a time consuming and frequently frustrating problem since you have to uninstall/reinstall over and over again to find the problems in scripts that run fine in Terminal, but blow up under the installer.

Anyways, after a 18 hours of testing and retesting, we have most of the problems worked out, and with a little luck, the remaining issues are variants of the ones we've already solved.

I apologize wholeheartedly for the delay, I can only say that it is probably more frustrating to me than it is for everyone else.

Problems with 8.3 preventing releas

Tue, 19 Feb 2008 11:08:07 -0500

Alright, just an update regarding 8.3. At the moment we are holding the release because while we have a PG that installs and runs, you cannot build software against it, and it flakes out on 10.4. We believe the problem is in our build environment and have torn down the i386 machine in the build farm to reinstall it under 10.4 and repatch it to a normal patch revision and rebuild the libraries using that. Initial digging shows evidence that the i386 build is what is causing the issues at hand.

8.3 Official Released, for Mac coming soon

Thu, 07 Feb 2008 09:57:09 -0500

Alright, the official release is out, and we are working to get the "for Mac" packages wrapped up and out the door. At this point, we have successful builds on x86 and PowerPC, but the x86_64 build is giving some problems in testing. Those should be resolved today, and the assembly of the universal binaries will proceed from there.

However, the GUI tools have not finished the transition to PGSQLKit, so in the interim, we will be shipping the existing pgCocoaDB tools, rebuilt against the 8.3 libraries.

In addition, we will be publishing the 8.2.6 release alongside the 8.3 binaries, as we finally got all the scripts reworked for the universal binaries.

Other fixes in this build are repaired uninstall scripts that use the correct dscl command instead of the old style netinfo commands.

8.2.6 and 8.3 coming in parallel

Thu, 24 Jan 2008 12:16:40 -0500

Alright, so here is the scoop on 8.2.6 (and 8.3). In both cases, the holdup is not the PG code in anyway. At issue are our build scripts. You see just before 8.2.6 was published we had made some changes to accommodate x86_64 as an additional build in the Universal Binary. The reason for this is that with Leopard, Apple switched the Apache binary and libraries to x86_64, and they then attempt to load the same versions down the chain. Obviously, PostgreSQL was one of those. So we altered the scripts to address that. Unfortunately, that change has exposed a series of flaws in the script design and has caused quite a few headaches in the release of these builds.

What I'm hearing is that we now have clean builds of each of the architectures that all pass the automated tests on their platforms, and that the lipo script that assembles them all into a neatly wrapped up universal binary is all that remains to be fixed. Unfortunately, I've been the roadblock there, as I spent most of last weekend helping my mother-in-law with her new house, and actually took last night off to catch a basketball game with my father and son. With that said, tonight should be spent on the scripts and testing, with a possible release Friday or over the weekend.

I would like to apologize for the delays, but we are really trying to make this release a little smoother than the last couple have been.

8.2.6

Mon, 14 Jan 2008 16:34:05 -0500

Over the weekend, we spent quite a bit of time with the 8.2.6 release, and things look very very good, however, we made a decision to not hold off on the inclusion of the x86_64 support. Unfortunately, that choice has caused a delay in the release. At this point, we are looking at the 19th of January for the publish. Perhaps sooner, but we want to get a clean run through the test suite before we roll this out.

Prepping 8.2.6

Mon, 07 Jan 2008 14:35:43 -0500

Last week PostgreSQL.org released version 8.2.6 to the servers. With the holidays, things have been crazy around the office (and it doesn't help that I took a week long vacation!). So the release didn't get rebuilt until this morning. We've got the build up and running and are testing it on the mini's right now. Assuming all goes well, expect the 8.2.6 for Mac revision to be published later this week.

PostgreSQL 8.3

Wed, 26 Dec 2007 10:52:41 -0500

Since there was very little interest in a PG8.3 prerelease, we will not start the release cycle of 8.3 releases until it has been officially released. That said though, 8.3 looks to be an excellent release for Mac users. Performance seems to be better, and as has been the case with PostgreSQL releases of the last couple of years, the features added are well thought out and should work well for most users. Not the least of which is the inclusion of tsearch2, which will make running many open source applications that originated with MySQL that much easier to install and run on PostgreSQL. This includes high profile applications like MediaWiki, which should now run against PostgreSQL without any additions.

Measuring Interest

Fri, 14 Dec 2007 16:44:44 -0500

With the PostreSQL 8.3 beta cycle starting to wind down, we are curious how many people would be interested in a couple of 'beta' builds pre-packaged before the release arrives in January.

If you have a serious interest, drop a message to dru AT druware.com , if there is enough interest, we'll get a build rolled and up on the servers for testing.

Financial Disclosure

Mon, 10 Dec 2007 10:56:46 -0500

With the year about to wrap up, it is time to talk about the money side of the project. This year, there was a little bit of donation money and a couple of expenses incurred by the project, and in the interests of transparency, we thought we would share with the community.

First, let's talk about the two primary contributors, ntiffin and hawkmoon. Both have worked hard in their spare time to make things work. While hawkmoon has don mos of the packaging, ntiffin put together all of the code that enables the schema tools in the latest Query Tool. There are also an handful of bug reporters and folks that have helped us track down and fix some little issues. These people have given of their time, and though it has no money value, it is just as big a donation as money.

But, that brings us to the subject of money. First let's discuss the expenses which in all honesty are minimal, and have been graciously absorbed by Druware Software Designs (Hawkmoon's personal business).

Expenses

* Web Hosting: $10 / month = $120 / year

* x86 build machine: Used Mac Mini @ $280

* ppc build machine: Used Mac Mini @ $399

Total Expenses for 2007: $799

Income

* Donations via SourceForge.net: : $84.90

* Misc. Revenue: $34.60

Total Revenue for 2007: $119.50

Hawkmoon picked up the tab for the Mini's personally, so between the donations and the other sources of income the project itself, basically broke even last year, which is excellent. Unfortunately, looking at 2008, there are a couple of wish list items that unfortunately have a cost with them. One of those is that we would like to migrate to a dedicated server for SVN, email and web hosting. Ideally this would be an xserve that we could also use to host forums and a bug tracker to get off of SourceForge, but at the moment, we are looking at 2009 for that to happen.

Budget for 2008

Based upon the 'want' list for 2008, a preliminary budget for 2008 is to continue the web hosting at $10 / month, and to purchase the service of an icon artist to create icons for the PG4Mac tools and toolbars. Estimated costs is about $2000 for custom icons that we can release under the BSD license. With that in mind, we are hoping to be able to coexist with Druware.com on the current server until 2009 before moving to our own server.

In conclusion, for a fledgling OSS project, we are doing well, though we would love to get a few more people involved, and 2008 looks like a big year, with Druware releasing several PG related tools and contributing large bits of code back to the the project in the process.

PostgreSQL 8.3?

Mon, 10 Dec 2007 10:44:09 -0500

With the soon to be released PostgreSQL 8.3 release, we are planning to start maintaining two trees. One for the current (8.3.x) and one for the older (8.2.x) releases. Assuming this works as planned, we will maintain the older branch until the PostgreSQL Group moves forward. In essence, this means two revolving versions, always the most current. So when 8.4 arrives, we'll drop 8.2, and roll forward from here out.

Second, starting with 8.3, we are going to stop using SF.NET to host the binary downloads, as we continue to have issues with mirror having old or bad binaries of the 8.2.5 revision. This should help prevent the problems some people are having with installations failing.

Happy Thanksgiving!

Thu, 22 Nov 2007 11:02:55 -0500

Just wishing all of our US visitors a Happy Thanksgiving Holiday, our best to you and yours.

Ruby on PostgreSQL for Mac under Leopard?

Mon, 05 Nov 2007 23:37:54 -0500

Turns out, it couldn't be easier. If you have the Unified Server installed, all you need is the command:

gem install postgres -- --with-pgsql-dir=/Library/PostgreSQL8

And if you don't, download he 'developer' package unzip it to the root, and use teh following:

gem install postgres -- --with-pgsql-dir=/opt/local

Current Downloads

Fri, 26 Oct 2007 10:20:33 -0400

The problems with the bad Client Tools has been found. The SourceForge download link is broken and pulling a bad archive (for reasons unknown). Using the alternate download will pull down the correct versions.

PGSQLKit Commit

Thu, 18 Oct 2007 12:12:03 -0400

It's official, the PGSQLKit framework code is now in SVN. This code is a first pass, and there is still quite a bit of tweaking to be done. At this point it is 'usable'.

Documentation is started, but is mostly stubs to this point.

More to come as we get some of the programs converted over.

Aqua Data Studio 6.5 Released by AquaFold

Wed, 17 Oct 2007 10:45:28 -0400

While we are building a robust suite of Mac native tools for PostgreSQL, there are several other options available out there. AuqaFold's newly updated Aqua Data Studio is probably the best. Certainly not cheap at $399 per user, it offers cross platform functionality for mixed environments allowing users to use the same tool on Windows, Linux or Mac OS X, to manage multiple databases, not just PostgreSQL.

Having used this tool a couple of years back, a couple of us involved with this project have been tracking it's progress, and with 6.5 it continues to evolve into an excellent product that we can wholeheartedly recommend to anyone that needs cross platform support at either the client or server end of the spectrum.

It's biggest weakness is that, despite it's otherwise excellent features, it is a Java application, and inherits some platform inconsistencies from that foundation.

Still some quirks

Wed, 17 Oct 2007 10:33:03 -0400

Well it looks like there are still some issues with the download, specifically with Leopard. We've got about 10 days to get those issues resolved, so look for another release, tentatively 8.2.5.2 sometime in the next 5-7 days.

Our Leopard machine has been having some issues which have now been sorted (bad hard drive in the iMac) and with those sorted out, we should be able to get some time to sort out the issues with the download.

Published 8.2.5.1 (Bonehead Repair Release)

Thu, 11 Oct 2007 16:18:14 -0400

OK, so sometimes we make mistakes, and lately, it seems to be a pattern. We checked everything, and the promptly published the wrong version of the Client Tools. Sad, but true nonetheless.

With that said, the download links have all been updated to reflect the correct version, and we have stepped the filenames to 8.2.5.1 to reflect the replacement. This fix addresses the missing pgCocoaDB.framework and the intel only issues in the client tools.

Introducing PGSQLKit

Thu, 11 Oct 2007 09:58:22 -0400

On the road to the next generation / iteration of the GUI tools, pgCocoaDB started to show some pretty serious design flaws. PGSQLKit is it's replacement. Written by the guys at Druware Software Designs, it will begin moving into the PostgreSQL for Mac code repository today, and is the foundation for future PostgreSQL for Mac tools, as well as the commercial offerings from Druware.

So, about PGSQLKit, what makes it 'better'? First, it has been designed to better integrate into the Mac environment. Second, it deals more gracefully with sharing itself across multiple uses. Third, it is being actively worked on. That's the dirty little secret about pgCocoaDB, it hasn't seen alot of active work in well over 6 months.

Which brings up the related subject of documentation. We are adding documentation for the PGSQLKit to this website under the 'Data Access' section, and you can peruse the documentation for the classes there. This documentation will also be available as part of the developer downloads as they are made available.

Published 8.2.5

Wed, 10 Oct 2007 17:19:12 -0400

Well, it's official, we've pushed 8.2.5 out the door. With a bunch of little tweaks to the GUI build process, and several bugs addressed, this should be the most solid release to date. In addition, we are continuing to move forward with some new projects built upon this effort. CD's should be available from Druware sometime next week.

Next up is a beta build of the official 8.3. beta code from PostgreSQL.org. Initial tests show this to be a very attractive incremental release, and we look forward to migrating to the 8.3 code as it nears completion.

Working on 8.2.5

Wed, 26 Sep 2007 09:29:07 -0400

So PostgreSQL 8.2.5 has been released in source form. We've got the source built and are in the process of testing and finishing up some changes in the distribution process. Hopefully these will wrap up this weekend and Monday we will make 8.2.5 available.

It will also be the first version of the installer to support Leopard.

Druware's PostgreSQL Automator Actions

Mon, 24 Sep 2007 16:50:32 -0400

Just a sneak peak at the new Automator Actions the guys at Druware are working on. This is the first screenshot of the working static query action. According to the developers, there will also be a dynamic query, a parameterized query, results to xml and results to csv actions as part of the package.

Oracle-like SQL Worksheet for PostgreSQL

Fri, 14 Sep 2007 12:12:36 -0400

While I come from a background heavily influenced my Microsoft's SQL Server, as do several of the PG for Mac contributors, there is another group in the world who come from a more Oracle centric background, where a different set of tools exist. While we haven't even begun to address the issue either at Druware or here, someone else else.

Toplica Tanasković, a Mac software developer from Serbia, has put together a very usable equivalent for Oracle's SQLWorksheet tool, but targeted at PostgreSQL. Called iPGWorksheet, it recently hit version 0.5, and is at this point a very usable alternative to the Query Tool or the command line psql tools, that should feel very comfortable to Oracle users. It is licensed under the GPLv2, and looks to be an excellent start on another great Mac native tool for PostgreSQL databases.

[Download] [Blog]

Upgrading a PostgreSQL Database

Wed, 05 Sep 2007 11:03:30 -0400

Something most new to PostgreSQL users don't understand is the process of upgrading the server. Unfortunately, it's a non-trivial exercise. One of the key tidbits is that when you upgrade a PostgreSQL server, you will need to back up the configuration files if they have been altered.

Because of the way PostgreSQL handles it's data and configuration files, any upgrade that crosses a minor version revision, y of a version like x.y.z, it is necessary to re initialize the data directory. Because of this it is necessary to backup the database prior to any upgrade. It is also necessary to backup the any customized .conf file from the data folder, so that the changes can be reapplied to the new files when they are recreated.

Notice, this is not a backup and restore the old files, as the format of these files frequently change across revisions.

In the future, the Mac version's installers will deal with this as gracefully as we can, but the problem will persist to a certain degree anytime you make changes outside of the graphical interface.

Coming Soon

Wed, 29 Aug 2007 10:04:15 -0400

We've talked briefly about PGSQLKit, now it's time to get into a bit more detail. Back in 2004 when I first started what is now the PostgreSQL for Mac project, I had very little real experience with Cocoa, and none with building a reusable framework for Cocoa applications. CoreData didn't exist and Enterprise Object Framework was a Java framework. There just wasn't much in the way of references. So I used what I knew of data access on the Windows platform to create what became the pgCocoaDB framework.

Unfortunately, the longer I used pgCocoaDB I realized some fundamental issue with the design and implementation. At the same time, some work related pressures led me to create the ODBCKit. Building ODBCKit gave me an opportunity to rework some of the designs concepts into a better toolkit. From a usability standpoint, ODBCKit i a better toolkit than pgCocoaDB ever was.

As time freed back up, and I got back to the PostgreSQL work, I realized that in order to get where I want to be, I needed to address the issues in pgCocoaDB. Unfortunately, that meant either completely breaking the current code and programs that use it, or starting over. I elected to start over, and the result is PGSQLKit.

PGSQLKit inherits much of the design of the ODBCKit, to the point that the interfaces are nearly identical. The two are a few #IFDEF's from interchangeable in a program. Which means that much of the work that goes into one can be reused on the other side. The plan, at this point is to maintain that, and put the PG specific extensions into a separate framework that builds onto PGSQLKit sometime in 2008, probably Q2.

So, what about the PGSQLKit, well if you've looked at the documentation for ODBCKit then you already know about the interface. Everything revolves around the PGSQLConnection class which implements all of the query and result tools. The other big item of note is the PGSQLLogin class, which is a helper class that also implements a login / connection selection dialog. That dialog now implements basic connection management using the Keychain and in the process removes some of the security issues in the PGSQLConnection class by allowing it to flush the password from memory as soon as the connection is established.

With the first commits on the new framework starting this week, this code is the future of PostgreSQL data access tools for the PostgreSQL for Mac project.

PGSQLKit Progress

Mon, 13 Aug 2007 15:53:25 -0400

The future replacement for the pgCocoaDB framework, the PGSQLKit framework has been in development now for a month or so, and it recently reached it's first milestone. Initially, this kit was not going to go open source, but after looking hard at the pgCocoaDB, it was decided that we would move this into the project and replace pgCocoaDB with the more robust, and truthfully, better thought out design.

Initial SVN checkin should happen in the next couple of weeks, from there it will be enhanced, and integrated into the existing tools, in addition to being the foundation for several of Druware's commercial offerings.

Leopard Issues

Mon, 13 Aug 2007 15:52:02 -0400

For those trying to install on Leopard, there is an issue where the preflight scripts fail. This is due to a change in the command line tools for user management. For the short term, the work around is to manually create the Postgres user account prior to running the installer.

Added HowTo's to the Server Pages

Thu, 19 Jul 2007 15:15:21 -0400

Last night and today, we added a couple of 'howto' documents to the Server section of the website to address a couple of very common questions with regards to the PostgreSQL for Mac installation.

Updated to 8.2.4

Tue, 29 May 2007 10:40:04 -0400

Updated the server to 8.2.4, and rebuilt all the clients tools to the current SVN and library. Fixed a few little bugs and added the schema browser to the Query Tool. Not much other than those changes though.

Bigger changes are still coming down the pipe, more on those as we can announce them.

Coming Updates...

Wed, 09 May 2007 14:53:29 -0400

With the recent update of the core PostgreSQL distribution to 8.2.3, it's time to do another rollup release. Tentatively, this is scheduled to be completed and ready for distribution on Friday May 25. That should give us enough time to finish some testing, but also to get the Query Tool updated to the latest SVN trunk code, which includes many new features (thanks Neil).

In addition, work has started on making the underlying framework for the Cocoa tools a little more 'user friendly'. Taking some cues from the lessons learned in pgCocoaDB and subsequently in the ODBCKit, the next major revision of the pgCocoaDB toolkit will feature some more readily reusable utility classes. One of those will be a common PostgreSQL Login screen. The Proposed panel includes saving a list of previously used connections and full Keychain integration.

While this new panel will not be available in this months release, we would like you to take a look at the screen shot and provide some thoughts.

Second, there is a desire to find a way to get the primary contributor's to be able to commit more time to this project. Since there is no money in giving software away, and there have been very little in voluntary contributions. We are going to be making some of the code available as commercial products. As a part of that, the distribution is going to move to a 'server' package that stays in sync with PostgreSQL version, and 'Tools' which will move to their own release schedules.

Fixed Download Links & SVN

Sat, 31 Mar 2007 10:13:25 -0400

Sorry about the confusion. Somehow the links to the SourceForge downloads got reversed. That has now been fixed. On the SVN side, some of the images in the projects got broken during the CVS import. This also appears to be resolved now.

This weekend should see the initial release of the PostgreSQL Automator Actions for Run Query and Run Dynamic Query.

Also of note is that the mailing list is now live, subscribe at SourceForge.net.

Source Moved to SubVersion

Sun, 18 Mar 2007 11:18:07 -0400

Thanks to Neil, the source code has been fully migrated to SubVersion from CVS. With that done, it is time to get some other projects rolling. First up, get all of the tools updated to the latest sources. Then it's time to get some other Mac-centric projects added to the library.

One of those is to build a collection of Automator Actions and example workflow documents to showcase some of the things that can be done with PostgreSQL and Automator. Some of this is derivative work to things I've already started for the ODBCKit project.

The other big project is to take the Query Tool and pump it up into something much more powerful, Neil has already provided much of the foundation to do this. Now it's on to fleshing out the user interface.

As you can see, there is also a new look the website. The old one really didn't look that good. Also new is a page about contributing to the project.

PostgreSQL 8.2.3 Update Now available

Sun, 11 Feb 2007 20:12:42 -0500

With the quick release of 8.2.2 and 8.2.3, we are skipping 8.2.2 altogether. Hoepfully in the future, we will be able to better track with the current PostgreSQL releases as this weekend was spent reworking, testing, reworking some more and isolating the build environment.

There are now two Mac Mini's sitting side by side: miniBuildPPC and miniBuildx86. miniBuildPPC is a 10.3.9 box configured to build PostgreSQL for distribution on the PPC, and miniBuildx86 handles the 10.4.8 Intel builds. Because the x86 is that much faster, it also handles the 'assembly' phase of the build process. This phase is used to merge the two build trees into a single universal tree using 'lipo'. The resulting product is then bundled into the .pkg installers and the DMG is created. With all of this completed, it is now possible to build the entire package in about 35 minutes instead of the 3-4 hours it took before.

Unfortunately, uploads to SourceForge still take forever, so while that updates, I have time to update the various PostgreSQL related websites, this one, my blog, and the Druware links.

With this update, I have also moved all of the code from SourceForge's unreliable CVS servers to the hopefully more reliable SVN servers. How that goes remains to be seen.

Finally, after a brief outage last week, the website has migrated to a completely rebuilt Xserve. Up until recently, it was doing multiple tasks. This presented a mess of problems, and to make matters worse, it was still running 10.3.9. It has now been formatted, added memory and is now on Server 10.4.8. I have also moved some of the services that it was formerly handling to another server.

Bugs!

Sat, 27 Jan 2007 10:02:05 -0500

There are times when I truly hate computers. It appears that the scripts that I use to build the packages went through some code rot because they generated an pretty useless package for the PostgreSQL 8.2 installer. I will try to get that resolved and republished later today or tomorrow.

PostgreSQL for Mac 8.2 Released

Fri, 19 Jan 2007 10:38:48 -0500

Alright, so it is several weeks late. Blame it on life and a need to get some paying work completed. To say that I have been busy would be a mild understatement. It also doesn't help that I had promised my family that I would finish a project in the basement by February, and am now pressed to get that done. Then there is that World of Warcrack addiction. Well, you get the picture.

Anyways, here's the deal. Obviously, the website has been gutted and rebuilt. That has been a project ongoing for over a month. As you can see, it remains a work in progress, but this is about as close as it is going to get until I can iron out some additional details.

The other tidbits. For the record, JBoss annoys the hell out of me. It's classloader is such that it is not well suited to running multiple applications in the same instance of JBoss. Tomcat handles it fine, but JBoss just gets fussy. It runs fine for a while and then blows up. Because of that, the Jira / Confluence combination is probably going into the trash. I'm going to have to just deal with SourceForge. I don't like it, but that's life.

New Website and Server

Fri, 15 Dec 2006 12:07:44 -0500

As you can see, I have gutted the old website, and moved much of this infrastructure over to a new server. You might ask why. The answer, is simple. The old one wasn't working, largely because JBoss does some things strangely, and that strange behaviour was crashing the bug tracking and wiki on a regular basis.