Hacktoberfest 2018

Glance at my Pull Request

Here is a short list about my Pull Requests and how they gone. The overall status can be cheked as usual.

pgenv multiple build support

In the last couple of weeks I spent some time working on pgenv, a PostgreSQL binary manager. The idea behind pgenv is to build, select (use) and control a single instance of PostgreSQL on the local machine, allowing the user to keep more instances available at her fingertips. Well, why not allow for building more than instance at the time? This is what this pull request is all about: the `build** command accepts a list of PostgreSQL versions to build, so that it is possible to specify something like: I closed this pull request because, after a discussion, we decided it was not so useful.
% pgenv build 10.5 11beta4 9.6.5
and get a coffee. The remove command has been changed similarly to allow the command to nuke more than one instance at the time.

pgTap table inheritance support

In this pull request I implemented a set of functions to test if a table has children. In particular, the following functions has been added to the pgTap suite:
  • has_inherited_tables and its counterpart hasnt_inherited_tables that allows you to know if a table has been used as a parent table;
  • is_parent_of and its counterpart isnt_parent_of to know if a table is n-th parent of another table;
  • is_child_of and its counterpart isnt_child_of to know if a table is the n-th child of another table.
In particular the last two set of functions has been implemented using the recursive CTEs feature of PostgreSQL, that drop support to version 8.4 and not before.

pgTap col_is_pk() variants

Anothe issue that caught my attention was about adding some new overloaded variants of the function col_is_pk(), that seemed a quite easy task. Therefore I created a pull request to do exactly that job, but while implementing it I found out that there was a potential clash between having arguments of type name and of type text (because essentially a name is a char[63]). This made failing tests in ambigous situations like:
SELECT col_is_pk( 'public', 'table', 'pk' );
because the server cannot choose between using a col_is_pk( name, name, name ) and a col_is_pk( text, text, tex ). By the way, I did a little refactoring and submitted the pull request, but oh gosh! I was testing on decent and recent versions of PostgreSQL, and the test suite was failing against 8.4 because of the introduction of format(). The point is I did not liked at all code like:
'Column ' ||quote_ident($1) || '.' ||quote_ident($2) || '(' || quote_ident($3)|| ') must be a primary key'
and thanks to format() (let’s call it an SQL-like printf(3) for PostgreSQL, it could be rewritten in a very more readable way:
format( 'Column %I.%I(%I) must be a primary key', $1, $2, $3 );
The problem is that format() has been introduced in PostgreSQL 9.1, so all prior versions were failing. Argh! Shame on me, I swallowed the string concatenation and did another commit to fix it back. But while doing all this stuff, I decided to take advantage of default arguments. Why having two almost identical representation of the same overloaded function? As an example:
col_is_pk( name, name, name, text )
-- implementation

col_is_pk( name, name, name )
-- implementation
The text last argument is the test description, that is not mandatory. But instead of having two functions, let’s use a single one with a default to null optional argument. The implementation pattern looks like:
col_is_pk( name, name, name, text DEFAULT NULL )
-- implementation
   coalesce( $4, 'Column bla blah must be a primary key' )
So, if the optional $4 text argument is provided, it is used, otherwise the coalesce function returns the default description.

www.itpug.org trophey patches

Yeah, these are really simply patches I did because the maintainer was responsive that day, not because I’m still involved with the user group or have changed my mind about it. Essentially:

pgenv patching feature

This pull request was a proposal for allowing pgenv to automagically patch the source tree it is going to build. Before this patch, there was some discussion about how to instrument pgenv for patching the source tree, and at that moment the script was doing a direct patching hardcoded into the script itself. My proposal was to use an index file, that in turn contained a list of individual patches to apply on the source tree. But in order to let the user and the system to be as much flexible as possible, I decided to provide several optional indexes based on a PostgreSQL-version and Operating System combination, so that the user and the pgenv maintainers could choose how to distribute their patches and build a *patch-archive** different from any OS and/or PostgreSQL version or part of it. I squashed this pull request on October 25th!

pgenv message verbosity

This pull request is a proposal for making pgenv configurable with regard to the amount of messages it does print. In particular the idea came into my mind from an issue asking for some more configuration. The idea is that almost every message printed out by the program is now printed via a specific function, named pgenv_message, that prints to stderr and only if the PGENV_VERBOSITY variable has a level of verbosity greater or equal to that of the message. This, of course, makes the usage of pgenv_debug obsolete, so that every call to pgenv_debug has been replaced to calls to pgenv_message with a level of 'debug'.

perlbrew clone-modules fix

This is related to some odd behavior of the command clone-modules that I implemented in the last year Hacktoberfest. The problem was that such command was expecting two version numbers to perform the cloning, a source and a destination, but only the destination was effectively used, while the source was always erronously set to the currently running instance. This pull request introduced the fix and also some extra check to avoid waste of time and resources while doing the cloning. The Pull Request was merged on November the 18th, but it contained a big, no wait, a huge mistake by me: I removed the list-modules command support because I was thinking it was no more used. Thanks the author was not drunk like me when evaluating such branch!

pgenv build-git command

As requested in an issue by Robert T. pgenv should gain the capability to build the current development version, that is the currently checkout out source tree. Therefore I thinked about it for a couple of days and introduced the special version dev and the related command, so that pgenv was able to fetch and build sources from the official git repository. I pushed in the wild a little too fast, so I had to make some other commits later on.

What I learned this year

This year was a little harder than the previous ones. Partially, it was because I committed to regularly propose my pull requests, that translates into a “less idea” principle. Second, because I tried to implement something more useful, dealing with new projects like pgTap. And it was from pgTap that I started learning how to deal with Continuos Integration and Travis.

The article Hacktoberfest 2018 has been posted by Luca Ferrari on October 31, 2018