Theory master #92
Closed
Theory master #92
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Enrivonment variable to force the configuration file.
There is now a configuration variable `PGENV_CONFIGURATION_FILE`
that, if set, will determine the path to the configuration file to be used
during all the operations.
This allows to decied which configuration file to use before the
`pgenv` starts working, so for example:
% export PGENV_CONFIGURATION_FILE=~/git/pgenv/config/default.conf
% pgenv build 16beta2
will use the default configuration file instead of a version specific
one.
The subcommand `config path` prints out the configuration
file path for the specified version, or the default one
if no version is specified.
In this way, it is possible to export the environment
variable like in the following:
$ export PGENV_CONFIGURATION_FILE=$( pgenv config path default )
If the user has defined the PGENV_CONFIGURATION_FILE variable
he probably does not want to overwrite a per-PostgreSQL specific
configuration file.
Close #60
This is already documented in the README.
#64) * Environment variable to prevent config file overwriting. The variable `PGENV_WRITE_CONFIGURATION_FILE_AUTOMATICALLY` is used to instrument `pgenv` to decide about the need to write/overwrite the configuration file at the end of a build/rebuild process. If the variable is not set, or set to a true value (i.e., not zero, not "NO" - case insensitive), the configuration file will be written and/or overwritten. If the variable is set to zero or "no" (case insensitive), the configuration file will not be written. Close #62
Implements the `status` command using `pg_ctl` as a way to check if the in-use instance is running or not. Work implemented by @briansalehi revised by @theory and @fluca1978 . Close #65
Since versions 1.x and 6.x have different tarball names and will probably not compile anymore in an automated way as `pgenv` does, remove them from the list of available versions for download and build. Modifies also the version detecting function, so that in the case a too old PostgreSQL version is required to be built (despite the `available` command not showing it), the program will complain with an error message explaining that only PostgreSQL versions 7.0 or greater can be managed via pgenv. Close #68
Bug detected in the usage of uninitialized PGENV_SED when `use`-ing a version. Introduced in commit e32acb0. See <#69 (comment)> See #68
For some strange reason, the post-initdb script holding variable was named `PGENV_SCRIPT_INITDB` but in the configuration was searched for as `PGENV_SCRIPT_POSTINITDB`. Since the configuration generates the latter, I fixed the test in `pgenv_initdb()` to use `PGENV_SCRIPT_POSTINITDB`. Bumps the version number. Close #70
This commit introduces a new configuration parameter `PGENV_SCRIPT_FIRSTSTART` that can be pointed to an executable that is run once and only once at the very first start of the selected instance. Therefore, the usage of this script enables for customization of the instance, like for example adding new users and databases. The changes are made directly into the `pgenv_start_instance` function, that is the entry point to a start action: the function in turns calls `pgenv_initdb` that performs the initialization of the instace. If the initialization is done, a new magic variable `PGENV_INITDB_DONE` is set to `1`, so that `pgenv_start_instance` can then decide to execute the script mentioned above. Therefore, the trick here is to mark a "first start" time as the one that immediatly follows the initdb phase. Documentation updated. Version number bumped. Close #71
Also ignore `.DS_Store` files that macOS sometimes creates.
If the user creates a directory in `PGENV_ROOT` with the same layour of another `pgsql-xxx` directory, and the name with the prefix `pgsql-`, such directory will be usable by `pgenv use` and subsequent commands. This allows, for example, to manage a checked out directory from another repository via `pgenv` as if it was installed by `pgenv` itself.
PostgreSQL 17 removed pre-compiled docs from the source tarball, including docs. The docs will now be built from source, but will fail if the required [DocBook tools] are not installed. To compensate, releases from 17.0 on are complemented by a docs tarball. We don't want to add the overhead of requiring the [DocBook tools]. So, when building Postgres 17 and higher, teach pgenv to use the new `world-bin` and `install-world-bin` targets to build everything except non-binary files, which includes docs. Then download and install the docs tarball and install its contents separately. Resolves #79. [DocBook tools]: https://www.postgresql.org/docs/current/docguide-toolsets.html
Fix typo in the `README.md` file
This commit introduces the possibility to handle per-major-version configuration files (e.g., `17.conf`) that are loaded in the case the version specific file (.e.g., `17.1.conf`) is not found on the system. The loading of a configuration file gives priority to the exact version, so for instance `17.1.conf`, then if such file is not found the program tries to load a `17.conf` (i.e., major mode file), and at last the `default.conf` file. Bump version to 1.3.9 Close #87
Rather than stop at the first configuration found, let each more specific config override variables from the less specific. The configs load in this order: * `default.conf` * `$major.conf` * `$major.$minor.conf` This allows a base level of configuration in `default.conf` and for more specific configurations to override its values. But keep the first configuration file loaded in the `PGENV_DEFAULT_CONFIG_FILE` variable so that it retains the user-specified file if it exists. Resolves #87.
Collaborator
|
I think you should rebase before opening another PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.