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.

Using the new JSONP callback support in the PGXN API, I just added a sidebar to my personal blog that shows a list of all my PGXN distributions. The code is simple:

<div class="links">
    <h2>PGXN Code</h2>
    <script type="text/javascript">
    function pgxn_distros(data) {
        document.write('<dl>');
        for (dist in data.releases) {
            document.write(
                '<dt><a href=http://pgxn.org/dist/' + dist +
                '>' + dist + '</a></dt>' +
                '<dd>' + data.releases[dist].abstract + '</dd>'
            );
        }
        document.write('</dl>');
    }
  </script>
  <script type="text/javascript"
     src="http://api.pgxn.org/user/theory.json?callback=pgxn_distros">
  </script>
</div>

And the output looks like this:

Not bad, eh? AS you can see, JSONP is dead easy to use with the JSON files served by the JSON API. Try that, CPAN!

sudo gem install pgxn_utils https://github.com/guedes/pgxn-utils #Awesome

Know Perl? Interested in PGXN? @-message me for an offer you cannot refuse.

Want to create a PGXN distribution? Dickson Guedes shows you how. http://pgcasts.com/media/pgxn_utils-usage-example.mpeg #SoAwesome

Following a pgxn-users discussion, I’m looking at adding a constraint on the names distributions can have. I’m thinking this:

CEATE DOMAIN namespace AS CITEXT
CHECK ( VALUE ~ '^[-a-z0-9_]{2,}$' );

So, just ASCII numbers and letters, dash, and underscore, with a minimum length of two characters. Maybe , and + should be allowed, too? What do you think? What constraints do you expect on distribution download file names?

Hrm. I wonder if the JSONP callback query param should be called “jsonp” or “callback”?

Updating the API server, might be some instability over the next few minutes.

By Daniele Varrazzo

During the last days I’ve done some lightweight hacking on the PGXN client, and I’ve just released the last package on PyPI, with the still very shy version number of 0.1a4.

First change: the package name. The package is now called pgxnclient, without the point. As Marti has commented, the point in the name could create problems to some distributions which may have needed to munge it into a shape fitting their naming constraints. So, in order to install the last release you will need the command:

$ easy_install pgxnclient

The name of the entry point script is still pgxn and it shouldn’t change.

One of the new features in this release is the addition of commands drop, to remove the the extensions of a distribution from a database (opposite of the load command) and uninstall, to remove installed files from the system (opposite of install).

Another change is the ability to work on a local zip or directory instead of using the API to get metadata and package from PGXN. The main goal of this feature is to help the packagers to test their packages with the client before submission, verifying that the data uploaded can be used in an automatized way.

A third change is in the install command: it previously required to be run as root if, as likely, the PostgreSQL directories are system ones. I was feeling this need slightly scary as download and build phases would have been run as root too, so now sudo is invoked by the script only when installing, with command line options allowing its customization.

What I feel mostly missing now is documentation: I know that adding it will force a big review of the code, adding missing comments, add tests to enforce what documented… so it’s something I will start tomorrow. Once documentation and code have converged there will also be a more sound basis to discuss about the client features. And dare version 0.2, maybe :)

Thanks everybody for the feedback. If you want to have a chat about the client or PGXN in general, the best place is the PGXN group. See you there!