Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alias command implementation #36

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Conversation

fluca1978
Copy link
Collaborator

Possible solution to #31 (part of the issue).
I propose this as a pull request because it requires a little testing and consideration.

The idea is to handle alias, i.e., other names, for installed postgresql verions. Each alias (i.e., name) is a link stored into the alias directory that points to the postgresql version.
All commands that accepts a version number (for installed versions) have been refactored to accept alias names also.
Documentation updated.

The idea is that this command allows the manipulation of PostgreSQL alias
names, stored as links into an `/alias` directory in the `PGENV_ROOT` directory.
Subcommands `add` and `remove` checks for the existance of the links
and create or delete such links int he alias directory.

Changes to the `versions` command in order to show also the aliases.
Now, after the directory output for each version, all aliases are printed out.
This changes the format of the `versions` output.
This way a user can specify a version to use/remove as an alias, and
the script will produce (normalize) the right version to use for disk layout.

Added a function to remove all the aliases of a version when deleting
an installation.
@theory
Copy link
Owner

theory commented Oct 17, 2019

Hrm. Would I be able to create two installs of 12.0, for example, one with PL/Python support and one without? Or is there only one instance of a given version allowed?

@fluca1978
Copy link
Collaborator Author

Hrm. Would I be able to create two installs of 12.0, for example, one with PL/Python support and one without? Or is there only one instance of a given version allowed?

No, the logic under the hood is the same, so as you cannot install two different versions right now, you are not allowed by aliases. Aliases, as in this implementation, are just mnemonic names for your instance.
In order to achieve multiple installations of the same cluster, we need to build an instance with a custom name. I imagine something like:

$ pgenv build 12.0 my-twelve-version

and create a my-twelve-version folder to use. But probably this will blow up versions that is no more able to understand that my-twelve-version is 12.0. Another option could be to build and create a folder likde pgsql-12.0-my-twelve-version and work with sed to extract all the information.

@theory
Copy link
Owner

theory commented Oct 20, 2019

Aliases, as in this implementation, are just mnemonic names for your instance.

Well then I guess my question would be whether folks would find that useful.

In order to achieve multiple installations of the same cluster, we need to build an instance with a custom name.

I like that approach.

But probably this will blow up versions that is no more able to understand that my-twelve-version is 12.0.

Yeah, we'd have to change it to look at the list of directories, and for each one that's apparently a Postgres instance, show its name and then the version in parens or something. Would have to look up the version for such instances by running pg_config --version or something. Or embed it in the directory name, as you say.

@fluca1978
Copy link
Collaborator Author

I could try to implement it, I've got some thoughts about how it does complicate the configuration management (that is based on the name too).

THIS BREAKS BACKWARD COMPATIBILITY.

Now each instance is installed into a directory that includes
a timestamp and is collected into a directory named by the PostgreSQL version,
for instance
 $PGENV_ROOT/
      pgsql-12.0/
              pgsql-12.0-2019-10-21-14-15-35
              pgsql-12.0-2019-10-21-08-36-35
     pgsql-11.5/
              pgsql-11.5-2019-10-20-14-15-35
              pgsql-11.5-2019-10-20-08-36-35

and each instance is automatically assigned two aliases:
- one with the version (12.0 for example)
- one with the full timestamp (pgsql-12.0-2019-10-21-14-15-35).

This means that the alias with the single PostgreSQL version (e.g., 12.0)
works only for the first instance installed.

All other commands have been refactored to use the alias as input.

Remove sed dependency in pgenv_versions.

Fix pgenv_versions to allow '*' on current instance.
The `alias remove` prevents the user to lock out removing all the aliases
of an instance.
The `add` command allows for alias creation.
@fluca1978
Copy link
Collaborator Author

I've done refactoring to allow for both aliases and multiple installations.

The idea is as follows.
build creates a PostgreSQL instance into a directory with the timestamp, then aliases the installation to the PostgreSQL version number. For instance pgenv build 12.0 builds pgsql-12.0/pgsql-12.0-2019-10-21-15-56-45 and creates the alias aliases/12.0 so that the user can still perform all commands using the version number.
All the commands now manage the version as an alias and resolve it to the right PostgreSQL installation dir and configuration. Configuration is still managed per-version number.
The alias command can now add new tags to a distribution and remove removes the aliases unless at least one remains.

This probably invalidates PR #37 (rebuild) since every time a build command is issued a new instance is created.
This breaks compatibility with older pgenv installations because the instance directory layout has changed.

It is worth testing it, so far I've compelted a normal workflow witha couple of 12.0 instances.
I'm updating documentation accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants