New features in pgenv

pgenv is a great tool to simply manage different binary installations of PostgreSQL.
It is a shell script, specifically designed for the Bash shell, that provides a single command named pgenv that accepts sub-commands to fetch, configure, install, start and stop different PostgreSQL versions on the same machine.
It is not designed to be used in production or in an enterprise environment, even if it could, but rather it is designed to be used as a compact and simple way to switch between different versions in order to test applications and libraries.

In the last few weeks, there has been quite work around pgenv, most notably:

• support for multiple configuration flags;
• consistent behavior about configuration files.

In the following, I briefly describe each of the above.

Support for multiple configuration flags

pgenv does support configuration files, where you can store shell variables that drive the PostgreSQL build and configuration. One problem pgenv had was due to the limitation of the shell environment variables: since they represent a single value, passing multiple values separated by spaces was not possible. This made build flags, e.g., CFLAGS hard to write if not impossible.
Since this commit, David (the original author) introduced the capability to configure options containing spaces. The trick was to switch from simple environment variables to Bash arrays, so that the configuration can be written as



where the CFLAGS and LDFLAGS both contain spaces.
To be coherent, this also renamed a lot of _OPT_ parameters to _OPTIONS_ to reflect the fact that they now can contain multiple values.

Consistent behavior about configuration files

pgenv exploits a default configuration file when no specific PostgreSQL configuration is found. The idea is that, if you launch PostgreSQL version x, an .pgenv.x.conf file is searched for, and if not found, the command tries to load the configuration from a default file named .pgenv.default.conf.
However, when you delete the configuration, the system did remove also the default configuration.
Therefore, since this commit, there is more consistency in the usage of the config subcommand.
In particular, in order to delete the default configuration you have to specify config delete defauòt explicitly, since config delete will no more nuke your default configuration. Moreover, the config init command has been added, so that you can initialize the configuration and then modify it by means of the config write command. Why these two commands? Well, config init will create a “default” configuration file from scratch with current default settings, while config write will modify the specified configuration.

There is more…

I’m currently working at another change in the configuration subsystem, so that you can keep all the configuration files into a single directory. The idea is to ease the migration of pgenv to a different machine (e.g., a new one), keeping your own configuration.