Re: registry vs. environment (was re:binary installer)

>> I think there are a couple of things about this issue that
>have not been
>> completely thought out.  Moving off of an environment based home
>> variable should not be taken lightly.  Switching the runtime
>environment
>> variables to use the registry will have several unintended
>consequences:
>>
>> 1. There are several warnings and messages in postgres that
>explicitly
>> make reference to environment variables...these now have to
>be changed
>> for the win32 port.

Or just a notice in the docs saying that the environment can be
populated from the registry, no? Since we'd still support environment
variables *as well*.


>> 2. Application software written in C for PostgreSQL ported
>from unix may
>> not necessarily work anymore (assumptions about PGDATA).

You mean application software that starts the postmaster on it's own? I
think those are going to have bigger problems than just environment
issues. If you mean things like user functions that *read* PGDATA, the
idea is still to set the variables from the data in the registry, so
there should be no difference for them (except if they puke on the
windows-style paths).

And client side environment handling should not be affected at all,
AFIAK.


>> 3. Just like the registry, the env has a system and a user
>area to make
>> settings.  By default, mysql puts it home directory into the system
>> area.  Nobody on the mysql lists seems to have a problem with this.

How have they solved the issue with multiple servers but only one system
area environment? You could change the names of the variables based on
instances, but that will be a lot more confusing, IMHO.


>> 4. Manipulating the environment is generally easier (either
>using SET or
>> parameter invocation from the command line) and has little/no win32
>> centric coding.

It is easier to manipulate *unless* you are running a service.
Manipulating the system-wide environment on win32 is not that easy. For
example, if you tweak it while running a command prompt, you have to
exit and restart the commandprompt for it to see the changes-.

AFAIK there has been no mention of removing the commandline parameter
passing. That would definitly be a bad idea.

It has no win32 centric coding, certainly.


>> 5. The PeerDirect port uses environment settings, and I
>found it easy to
>> work with...why fix something that isn't broken?

For a lot of windows admins, it will certainly be considered broken.
Win32 programs are generally not configured this way. Also, see above
issues about for example multiple instances.


>The win32 TODO now has:
>
>    Store settings in the registry and set environment variables in
>    the process
>
>What additional things to we need to deal with if we go the
>direction of
>having the environment variables set from the registry and read-only in
>the process?

I still beleive this way of doing things will be the best. If you want
it in the system environment, you can use that. If you put it in the
registry (service specific, for example), that will override those
settings and be used instead.

Depending on how services are implemented, this might not even need to
be inside the postmaster/postgres backend. If we chose to use an
external service wrapper (capable of dealing with our signals, still, so
it has to be pgsql-specific), we can have that one populate the
environment for the postmaster.


//Magnus