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:
CREATE OR REPLACE FUNCTION
col_is_pk( name, name, name, text )
-- implementation
CREATE OR REPLACE FUNCTION
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:
CREATE OR REPLACE FUNCTION
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.