>> Also, it wouldn't solve the problem. say you had 8.0.0rc1
>installed and
>> wanted to install 8.0.0beta4 as well because some testing would be
>> needed. You'd break your 8.0.0rc1 installation... It's not as common,
>> but it might happen. (It's still going to give you rpoblems
>if we do it
>> right since your beta4 will run with the rc1 DLL file, but
>it's not that
>> common to need to rollback the DLL file as it is to need to
>do it with
>> the backend, I suppose)
>>
>>
>> (This is all because we support multiple versions installed
>at the same
>> time. MSI has functions to uninstall previous versions automatically,
>> but we certainly don't want to force that)
>
>We allow installs of various versions of PostgreSQL on Unix
>because each
>install directory is self-contained. Are you saying the use
>of SYSTEM32
>to store the DLL has broken that for Win32?
Yes, unless the version number is always increased and the file is
backwards compatible API-wise. As long as that is true, we are safe.
>Logically I have no problem with having the libpq.rc file
>updated before
>release but the way it works I am sure there is going to be major
>breakage as people forget to do this. In fact it should be updated for
>every new version of the installer or you might not get the new
>libpq.dll, and that seems unmanagable.
No. It only needs a new version number when it's *changed*. A new
version of the installer does not change libpq.dll, it just packages it
up.
Now, if it's changed and it's not updated then yes, there will be
breakage.
//Magnus