Skip site navigation (1) Skip section navigation (2)

Re: Version numbers on libpq.dll

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Subject: Re: Version numbers on libpq.dll
Date: 2004-12-14 17:25:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
Magnus Hagander wrote:
> > It is more complicated than that.  First, people building 
> > from CVS will just install everything in /bin and /lib and 
> > put nothing in SYSTEM32. 
> Yes.
> > You have to add the /lib to your %PATH% for anything to work, 
> > or copy the DLL into /bin.
> Correct. And doing so will *override* the one in SYSTEM32. I use the
> copy-to-bin myself all the time since that makes sure there is NO WAY
> I'm working off a wrong libpq. The downside is that I have to make one
> copy for psql, one for pgadmin, one for <test program a>, one for <test
> program b> etc.


> > Second, if two installers are created during beta2, they are 
> > going to have the same version numbers and will not be 
> > updated, so a fix to libpq will not get propogated.  I see no 
> > way to manage that except having the installer do it.
> Like I've said repeatedly, we do not plan to put out installers with
> in-between-beta builds. We've done so in the past for some reasons, but
> now that both pg for win32 and the installer is more mature, we're not
> going to do that. And if we are required to do that for some reason at
> some point, I'm sure we can bribe someone to bump the version number
> between betas as well. Since that is definitly an *exception*, and not
> the rule.
> I don't think this is an issue.

I question whether any of us will remember to modify libpq.rc if you
happen to be making a new installer twice in the same beta.  As a group
we forget even simpler things regularly.  And we would be adding an
additional change for each beta and each RC for only the installer.  I
am not inclined to add more work to a process that already is pretty

However, that is Marc's roll and he can answer whether he can do it
reliably.  I am not involved in that process.

> > The libpq.dll in SYSTEM32 and /lib will be different in that 
> > SYSTEM32 will have the updated version stamp, but it is my 
> > understanding only the installer cares about those version 
> > numbers, so that seems OK.
> Not sure that I follow this part completely. If you build from cvs and
> follow the default stuff, you will have the libs for the cvs version in
> that versions local directories and those apps are not affected by
> what's in SYSTEM32 (assuming you copy it from lib to bin, which you will
> probably know to do if you're building off cvs. We are trying to solve
> the problem for the "big masses", not for the developers. Developers
> will probably not use the installer)

My point is that installing from CVS will always overwrite libpq.dll in
/lib, so it doesn't care what the version stamp is in the binary.  Only
the installer cares about the internal version stamp.

> I agree very much with Toms comment about the fact that the installer
> project should *NOT* modify the files unless absolutely unavoidable.

Only the installer cares about the version stamp so the most reliable,
clearest place to set that value is in the installer build.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2004-12-14 21:01:49
Subject: Re: Version numbers on libpq.dll
Previous:From: Magnus HaganderDate: 2004-12-14 15:31:13
Subject: Re: Version numbers on libpq.dll

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group