Yesterday was a busy day. In addition to making the first PGXN release, I updated the fundraising spreadsheet and then the thermometer displayed on the main site. The good news is that things are coming along nicely. Thanks to recent contributions from Command Prompt, Marchex, Hitoshi Harada, and 25th-floor, we are now just $2500 short of our goal of $25,000. Thank you all!

Can you help us get to our goal in time for PgWest 2010, which is November 2-4 in San Francisco? I’ll be giving a talk there, “Building and Distributing PostgreSQL Extensions Without Learning C”, in which PGXN will of course be featured. Would be great to announce that the fundraising was successful.

As for the time I’ve put in so far, I’m happy to have PGXN Manager up and working, but of course it has taken more hours than I expected. 76.5 so far. I’d estimated 40. Meanwhile, the database design is up to 43 hours from the estimated 24. And that doesn’t count the hours I spent chasing shiny yaks and shaving them, like SemVer and Router::Resource. Those of you who estimate development projects, take heed! I clearly need to double all my estimates before I submit them.

Still, with the fundraising nearly done, I’m committed to finishing this project. I view it as a project budget, and so that’s what it will be, whether or not it takes me twice or four times as many hours as I’d estimated.

That said, you could help. Right? PGXN Manager is in good shape, but it’s not done. If you’d like to roll up your sleeves and contribute some code, please fork it, build it, and hack what you can. A few things on the to-do list:

• Add user admin interface. Should include checkbox to make and remove administrative permission
• Add mirror admin interface
• Add extension ownership permissions interface

The database API is there for these bits already; the code would mainly be in Perl. Hit me on #pgxn on Freenode if you want to help.

If documentation is your thing, contributions there would be appreciated, as well. In particular, the About PGXN page is a bit thin. Other interfaces will need help, too. More on that as we add users.

Thanks everyone for your support!

I spent most of the time I had to work on PGXN the last two weeks creating the database for PGXN Manager. I had estimated 24 hours of work to design the database. So far I’ve logged 34 hours. But I think that will come out in the wash, really, because I did a lot of work to generate JSON from database functions. This is code I had originally expected to do in the app layer. I’m starting work on that this week, with an estimated 40 hours. Hope I can do it in 30. :-)

I’m pretty happy with how the database API is turning out. See the nifty database API documentation I whipped up using gendoc and embedded MultiMarkdown. There are still a few tweaks I need to make. I just checked in a change to eliminate all the ALIASes I blogged about last week. Turns out that one can just function-name-qualify the function parameter names. Who knew? I sure didn’t.

But I do have a question for you, dear readers. Right now, the database requires that extensions have unique version numbers in every distribution. So if, for example, you uploaded the distribution foo 1.2.2 with the extension bar 1.2.2, when you next uploaded foo 1.2.3, bar could not be 1.2.2. I designed this this way by following my own practice of always incrementing the version numbers of all modules included in my CPAN distributions. So all modules have unique version numbers, with never a duplicate.

However, CPAN itself only cares that distributions have unique version numbers. It doesn’t care about the version numbers of included modules. See, for example, HTML::Mason. Note that the various included modules have all sorts of different version numbers, and many have no version numbers at all. So while the core module has a version number (1.45 at the time of this writing), if you click to look at older versions, say Mason 1.44, you’ll see that no other modules have their version numbers changed.

I don’t think I want to allow extensions without version numbers on PGXN. That’s been a recipe for many annoyances with CPAN. But maybe I should allow extension version numbers to repeat? The upside is less maintenance for multi-extension distribution authors. The downside is potentially less accuracy in the determination of prerequisites.

For example, say that we have two versions of distribution foo:

Distribution	Extensions
foo 1.2.2	foo 1.2.2 bar 1.2.2
foo 1.2.3	foo 1.2.3 bar 1.2.2

Note how the version number of extension bar has not changed between releases. But if I was a user of both foo and bar, and I specified that I required bar 1.2.2 but was actually using stuff in foo 1.2.3, I could end up with errors because I would only have foo 1.2.3.

This is an issue periodically faced by Perl hackers. I might require HTML::Mason::ApacheHandler 1.69 but really what I need is HTML::Mason 1.44. Of course, as a Perl hacker, it’s my responsibility to make sure I require exactly what I need, but sometimes it’s not clear what’s the primary module in a distribution. And if I don’t realize that the version number of HTML::Mason::ApacheHandler doesn’t change with every release, I might make mistakes.

Maybe that’s okay. Maybe PGXN should be less rigid like this. But I’m leaning toward keeping things as they are and requiring new versions of every extension in every upload of a distribution. It’s a bit tougher for those (few?) hackers who will create multi-extension distributions, but probably more reliable for everyone else.

What do you think?

Anyway, I’m getting to work on the Web app this week while this issue percolates. Been studying up on Plack. So nice!

I decided to get on creating the PGXN logo sooner rather that later, both to create a stronger identity for the project and to have a uniform look across the various services (the site, blog, twitter stream, identi.ca, etc.). So I began hunting around for useful iconography to inspire a design direction.

Let me tell, you, that’s a lot easier than it sounds. After browsing through images returned for queries such as “pixin,” “pig skin,” “zen,” “zen stones,” “pixies,” and god knows what else, I finally focused on “database icon.” This was much more useful, as I hit on images such as the one to the right. Pretty standard database icon, right? Three disks stacked up. I’m not sure why this is the classic graphical abstraction for a database, but I’ve seen it a zillion times. So often that it’s a cliché.

Much more interesting was stumbling onto the icon to the left. I love how three disks have been broken down to their simplest possible representation. Because I’m familiar with the cliché, I can see at a glance exactly what this icon is supposed to be. So I thought that might be useful to use.

Searching for “extension icon” was a bust. Most of the relevant images, like the one to the right, seemed to be related to Adobe Extension Manager (try to find a link for that!). I didn’t want to go near that, of course. But, inspired by the CPAN logo, I searched for “library icon.”

Bingo! I hit on the amazing icon at right. Of course! Gears make a great icon for extensions, don’t you think? This folder is like an extension library folder. So then I thought, how can I combine these two icons, the abstract database and the gear?

Well it’s simple, isn’t it? The database icon can be the holes in the extension gear. It’s punched out, right? PGXN will offer loads of database extensions to download (we hope), and when you use one in your database, PostgreSQL will, you know: turn the gear. It just fits.

Strongrrl created the logo and type treatment based on these ideas, adding the tilt and the figure/ground reversal, and I really love it. It’s a really great logo for a database extension site. I imagine I can use variants of this throughout the final design.