by Dickson S. Guedes

Hello everyone!

This was a productive weekend that allowed me to work on some new features in pgxn_utils and I’m proud to tell you that a new version was released!

Trying to simplify your extension-development life I’ve added two tasks to pgxn_utils: change and bundle. The first one is just a convenient way to change META information about extension, incrementally, the second one is an easy way to archive your extension in a zip file well named.

To install it just type:

gem install pgxn_utils

Or, if you don’t want to install it yet, see it in action on this screencast [3:05].

Work in progress…

I’m working now to simplify the release, creating a task to send bundled file to PGXN.

There are a lot of work to do yet so, please, tell me if you found a bug or have suggestions.

Have a nice code! “:)

by Dickson S. Guedes

Do you ever have problems with copy and paste? I often did, and that is why I create custom templates for often used files that match certain patterns.

With files from the structure of PostgreSQL’s extensions was the same thing.

I was tired of creating the files and edit the META, controlfile, READMEs, etc. every time I start a new extension and felt that I need something that made me more productive, so I decided to create an automatic generator and share it with the world.

I called it pgxn-utils, and you should give it a try: it is easy to install, easy to use and will help you to start hacking quickly!

How?

1. First install it:

   gem install pgxn_utils
   

2. Then start a new extension:

   pgxn_utils skeleton my_cool_extension
   

Thats all! It will create the initial skeleton for you and you can start coding! But, if you don’t want to install it, see it in action

Good hack!

I updated the howto yesterday. This document explains how to create a PGXN distribution. If you’re interested in releasing PostgreSQL extensions on PGXN, this document is worth a read.

In essence, it’s really simple: Just create a META.json and upload. But to get the full benefit, there are quite a few other recommendations. Already familiar with it? Here’s the checklist:

• Create a META.json
• Create a control file
• Create a Makefile
• Implement the code in the sql and src directories
• Write tests in the test directory
• Write a Text::Markup-recognizable README
• Write Text::Markup-recognizable documentation in the doc directory
• Consider including other files: Changes, LICENSE, INSTALL, COPYING, AUTHORS
• Release it!

Be sure to read the howto for details. Got feedback or suggestions? Leave a comment!

Oh, and check out pgxn-utils and simplify your extension-development life.

So I’m designing the full text indexing for the PGXN search site. I’m modeling it on CPAN Search, which has been great. There are four search options:

• Full documentation search. This is the most common. Includes doc title and body.
• User search. Search on names, nicknames, email addresses, URIs, etc.
• Distribution search. Search on distribution name, abstract, description, tags, and the README.
• Extension search. Search on extension name and abstract.
• Tag search. Search on tag name only.

The documentation search is the one I’m perhaps least sure about. It assumes that each extension in a distribution will have documentation. But so far that has not really been the practice for PostgreSQL extensions. Most folks seem to stick the documentation in the README. And even then it can be almost nothing. So a search for “count nulls” probably would not find “countnulls” extension, because there is no documentation. What should I do about this? I’m thinking one of:

• Encourage folks to write documentation. I’m going to do this anyway, because the docs will really help the visibility of an extension on the site. It looks like this. If you have no docs for an extension, your extension will not appear in the search results (or perhaps it might, but link to the distribution).

• If there is no documentation for an extension in a distribution, index the README as the documentation. I’m not really keen on this idea, because the README should describe the distribution, how to install it, etc. I’m planning to use it in the distribution-specific index. Documentation of the extension should be more about how the extension works, what it’s interface is, etc. Or so it seems to me, at least (I’m admittedly biased to this practice among CPAN modules). But at least with this approach there would be a link to “documentation” for an extension on the search site.

Erm, not really thinking of any other options. I feel pretty strongly that folks should write docs for their extensions, as much as possible, and I’ve set things up so that, from PGXN’s point of view, at least, you can write documentation in whatever format you like (assuming the format is supported by or added to Text::Markup), as long as they’re in a doc/ or docs directory. I want it to be as easy as possible. But I also want there to be decent search results ASAP.

Comments?