Add Support support for additional environment variables

[theory]

In order to build Postgres 16, I added this environment variable to default.conf:

export PKG_CONFIG_PATH="/opt/homebrew/opt/icu4c/lib/pkgconfig"

This works fine for the build, but not any subsequent build, because the variable isn't copied to the version-specific config. I'm wondering if we could have one of two things happen (or maybe support both):

• Copy non-PGENV variables set in the default config to the version-specific one. Might require some additional PGENV_ variable to create a list of such variables?
• Prevent the creation and use of version-specific config files. I just don't need them, so might be nice to have an option for pgenv not to create them automatically, only via pgenv config write

Thoughts?

[fluca1978]

The simplest idea, both for the implementation and the user, is probably to warn the user at the build phase about a missing configuration file (as it is today) and skip the write process once the build is finished. In this way, the user has to explicitly create its own configuration file. The problem, however, is that every custom setup used at build time will be lost, at least for the PGENV_* variables.

I would go for a solution like this:

• use the default file is none is found for a specific version (as it is today)
• warn the user at build time that he has to either produce a specific configuration file or the default will be used
• avoid writing a specific configuration file at the end of build
• warn again the user about the fact that he will use a default configuration file

I would prefer then to add a kind of build option so that the user can decide to have a per-version configuration file written or not. Something like pgenv build 16beta2 config that will produce the configuration file at the end,. while pgenv build 16beta will not.

May I proceed?

[fluca1978]

What if we implement a tag like syntax? For example pgenv build 16beta2 works as usual, i.e., build and write configuration files. pgenv build 16beta2@default builds the server using the default configuration file and does not write any new configuration file. ~pgenv build 16beta2@15.4` builds using the 15.4 configuration file.

I also wonder if it does make sense adding a pgenv config link 16beta default to link the configuration file to the default one, with the risk that the user does not understand that editing one is like editing the other.

[fluca1978]

After lunch my brain seems to work better. What about a way to indicate to pgenv which configuration file to use? For example let's use an environment variable PGENV_CONFIGURATION_FILE to make pgenv load such configuration instead of a per-version specific one. In this way, you can accomplish the usage of the default configuration file by simply doing:

% export PGENV_CONFIGURATION_FILE=~/git/pgenv/config/default.conf

and use pgenv as before. This will also make possible to handle configuration files in other custom locations, as well as custom named ones. And of course, we can add a pgenv config use default kind of action to let pgenv set the environment variable for us.

[fluca1978]

@theory can you please give a try at #61 and see if that works for you? The idea is to either:

export PGENV_CONFIGURATION_FILE=foo.config
pgenv build 16

or

export $( pgenv config use 15.4 )
pgenv build 16

The pgenv config use is inspired to ssh-agent and its environment variable printing.

[theory]

Left a couple comments; I think it might be useful just to print the path to the file, rather than an environment variable declaration. Maybe an extra command or arg to make it the environment variable path, but I'm just gonna set it up to use the default and probably not pay much attention after that.

Does it skip creating a version-specific file?