Glance at my Pull RequestHere is a short list about my Pull Requests and how they gone. The overall status can be cheked as usual.
In the last couple of weeks I spent some time working on
pgenv multiple build support
pgenv, a PostgreSQL binary manager. The idea behind
pgenvis 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.
and get a coffee. The
% pgenv build 10.5 11beta4 9.6.5
removecommand has been changed similarly to allow the command to nuke more than one instance at the time.
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 table inheritance support
has_inherited_tablesand its counterpart
hasnt_inherited_tablesthat allows you to know if a table has been used as a parent table;
is_parent_ofand its counterpart
isnt_parent_ofto know if a table is n-th parent of another table;
is_child_ofand its counterpart
isnt_child_ofto know if a table is the n-th child of another table.
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
nameand of type
text(because essentially a
char). This made failing tests in ambigous situations like:
because the server cannot choose between using a
SELECT col_is_pk( 'public', 'table', 'pk' );
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:
and thanks to
'Column ' ||quote_ident($1) || '.' ||quote_ident($2) || '(' || quote_ident($3)|| ') must be a primary key'
format()(let’s call it an SQL-like
printf(3)for PostgreSQL, it could be rewritten in a very more readable way:
The problem is that
format( 'Column %I.%I(%I) must be a primary key', $1, $2, $3 );
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:
CREATE OR REPLACE FUNCTION col_is_pk( name, name, name, text ) -- implementation CREATE OR REPLACE FUNCTION col_is_pk( name, name, name ) -- implementation
textlast 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:
So, if the optional
CREATE OR REPLACE FUNCTION col_is_pk( name, name, name, text DEFAULT NULL ) -- implementation coalesce( $4, 'Column bla blah must be a primary key' )
$4text argument is provided, it is used, otherwise the
coalescefunction returns the default description.
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:
www.itpug.org trophey patches
- a little text over here and there
- removal of the italian planet, since it was not working anymore (and this commits to the fact ITPUG does not seem to be interested in keeping a planet, neither a blog update).
This pull request was a proposal for allowing
pgenv patching feature
pgenvto automagically patch the source tree it is going to build. Before this patch, there was some discussion about how to instrument
pgenvfor 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
pgenvmaintainers 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!
This pull request is a proposal for making
pgenv message verbosity
pgenvconfigurable 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_VERBOSITYvariable has a level of verbosity greater or equal to that of the message. This, of course, makes the usage of
pgenv_debugobsolete, so that every call to
pgenv_debughas been replaced to calls to
pgenv_messagewith a level of
This is related to some odd behavior of the command
perlbrew clone-modules fix
clone-modulesthat 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-modulescommand support because I was thinking it was no more used. Thanks the author was not drunk like me when evaluating such branch!
As requested in an issue by Robert T.
pgenv build-git command
pgenvshould 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
devand the related command, so that
pgenvwas 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 yearThis 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
pgTapthat I started learning how to deal with Continuos Integration and Travis.