On Sat, Oct 4, 2008 at 1:53 AM, Martin Gainty <mgainty@xxxxxxxxxxx> wrote: > When the Windows Installer is out of synch with the installed MS binary as > what happens when you install a Windows Service Pack your install may only > partially install leaving the installation in a unusable state where you > would then have to > 1)clean out the registry for all of the entries for the program (exes) and > all of its associated dependent dlls > 2)delete the installation root folder (and all associated programs) > 3)delete any/all links/aliases to those programs None of which applies to PostgreSQL (or a Windows Service Pack). The only shared DLLs which PostgreSQL 8.3 uses are are the VC++ 8 runtimes, which are installed as versioned assemblies. Multiple versions of the runtimes can be installed simultaneously, and the binaries bind automatically to the correct version. PostgreSQL 8.2 used the MSVC++ 6 runtimes, which have never had a non-backwards compatible update. This applies also to other components such as COM objects and ActiveX controls which may also be updated with a service pack. Any compatibility breaks are accompanied by a CLSID and filename change specifically to ensure that both versions can coexist to prevent breakage of third party apps. The kind of breakage you refer to typically comes from third party apps that install libraries in shared locations and break compatibility without regard for the consequences. We were guilty of this with PostgreSQL 8.0, in which we installed completely un-versioned SSL libraries as well as libpq.dll in %SYSTEM32%. Suffice it to say, we fixed this. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
