On Sat, Oct 4, 2008 at 1:53 AM, Martin Gainty <mgainty@hotmail.com> 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