-
Notifications
You must be signed in to change notification settings - Fork 29
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
base: master
Are you sure you want to change the base?
Conversation
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.
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.
and create a |
Well then I guess my question would be whether folks would find that useful.
I like that approach.
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 |
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.
I've done refactoring to allow for both aliases and multiple installations. The idea is as follows. This probably invalidates PR #37 (rebuild) since every time a build command is issued a new instance is created. It is worth testing it, so far I've compelted a normal workflow witha couple of 12.0 instances. |
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.