General suggestions (can break into separate tickets)

[Ovid]

This isn't to create an issue per se, but to discuss a few things I saw yesterday that are still fresh on my mind while using pgenv for the first time. If any seem relevant, happy to create separate issues for them.

First, let me just say this is an awesome tool. Thank you for it :) I don't think an issue is required for this.

New subcommand: alias

We like to have a lot of our deployment workflow for the Tau Station MMORPG involve aliases. Thus, if we want to sqitch deploy some major databases changes, we'd love to have an alias:

pgenv build $pg_version
pgenv alias $pg_version veure
pgenv use veure
bin/setup/install-sqitch
sqitch deploy

And with that, we then safely proceed with our regular deployment and restarting our servers automatically point to the correct database. If something goes wrong ...

pgenv alias $pg_previous_version veure # removes current alias

And then we can roll back our changes and restart the servers. Players may have lost some game action, but hopefully not too much.

Of course, the remove, current, and versions commands may need to be aware of the aliases.

New subcommand: rebuild

pgenv rebuild $pg_version
pgenv rebuild $pg_version --keep-config

More or less equivalent to:

pgenv clear # if you're using the current version
pgenv build $pg_version

However, the --keep-config option would make it trivial for someone to edit the $pg_version config and, say, add --with-uuid=ossp for older PostgreSQL's and not worry about the 5 second window which has bitten me several times when reinstalling with pgenv:

        # warn if no configuration was loaded
        if [ -z "$PGENV_CONFIGURATION_FILE" ]; then
            echo "WARNING: no configuration file found for version $v"
            echo "HINT: if you wish to customize the build process please"
            echo "stop the execution within 5 seconds (CTRL-c) and run "
            echo "    pgenv config write $v && pgenv config edit $v"
            echo "adjust 'configure' and 'make' options and flags and run again"
            echo "    pgenv build $v"
            echo
            sleep 5
        fi

Alternatively, have a workflow change whereby pgenv simply halts on -z "$PGENV_CONFIGURATION_FILE" and prompts if you wish to continue (with an optional flag to pgenv build to skip this check when people want deployment automated).

Warn if current data directory?

Not sure how this is handled by PostgreSQL, but this bit me hard yesterday (particularly as I was working with an old, slow computer).

I needed to upgrade PostgreSQL from 9.3.5 to 9.6.2. pgenv was a breeze my first time around, and then I got this:

$ psql taustation
Null display is "[NULL]".
Expanded display is used automatically.
psql (9.6.15) server (9.3.5)
Type "help" for help.

I actually didn't notice this until a long sqitch deploy failed midway due to an incompatible data type. This was because I had an older pg installed. So I did brew uninstall postgresql and it removed it, but the problem remained because I had an old data directory lying around (I don't know if homebrew doesn't remove that or if it was from a previous build, but the versions were the same).

I finally manually deleted the data directory and everything built nicely. However, if there's some way to detect if PostgresSQL is going to use an existing data directory, it would be nice to know that.

Update: fixing many typos in the above because I was very sick when I wrote this. Sorry if it was confusing at times.

[fluca1978]

Thanks, these are interesting suggestions.
I've been thinking about an alias command for quite some time, so I think this must be implemented.
I'm not so sure about the rebuild, since that must keep the $PGDATA in my opinion.

I'll take a look at every point within this month.

[Ovid]

Could we have an option to allow different $PGDATA? We could then have multiple instances of PG running against different databases and this could make our life much easier, if possible.

Debian has clusters. Not sure about other operating systems.

[fluca1978]

@Ovid do you mind have a look at two pull request that should do what you asked for?

[fluca1978]

@Ovid I've also implemented a very straightforward psql command that will execute the correct version of psql, so it should avoid the last problem you reported.
I'm in doubt if psql command is the right way of implementing it, rather than warning the user if the currently installed postgres is not in the PATH.

[fluca1978]

@Ovid now the master branch supports warning in the case your PATH is "wrong", provides rebuild so at least half of this issue has been solved.
There is still the discussion about #36 that would allow both "aliasing" and supporting multiple installations of the same version.