Re: Version numbers on libpq.dll

>> 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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match