Re: Version numbers on libpq.dll

>> >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.
>
>OK, so how do they get multiple libpq.dll's in that directory? Is a
>number added to the end of the file name or are both libraries bundled
>in the same file?

No, they will both use the latest version of the library.

>> >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.
>
>Right, but my point is that libpq almost always changes
>between versions
>of the installer, even during beta. It might be an API change or just
>new code in the functions but it changes quite frequently.

Right. Which is why we need to bump for each beta.

>Also, the installer builds are not released to match the beta
>releases.
>What if you do two installer builds during the same beta and libpq
>changes? You need those changes to be installed.

The plan is to release only on official betas. The reason we didn't do
that "the whole time" was that the installer wasn't ready so we more or
less had to. From now we're only planning to put out installers
containing official builds, even if we put th einstaller out in-between
betas.

>The idea that someone is going to update that version string every time
>there is a change to libpq isn't going to happen reliably if at all.
>Maybe that value should be set by the installer to be the
>number of days since 1970.

We could set it when building the installer by hacking up the DLL file,
but that's really ugly, because then there would be no correlation with
the official version numbers. And we claim to ship the official
version...

Perhaps the build system could be made to derive it in "days since 1970
that the last commit to configure.in was made"? Would still break the
MSVC builds, though.

>I think you are best forcing an install based on the version string in
>libpq.rc as it is updated now and not allowing beta1 and beta4
>to run on the same machine.

Well, we're going to have a problem with all those who have already
installed. Not to mention those that installed rc1, then release, then
uninstalled rc1. They will *think* they have the release version, but
theyw ill not. And there will be no other way to find that out other
than doing a md5sum on the file and compare.

> I think our dynamic load machanism enforces
>a similar
>limitation with Unix unless people are very particular in how they set
>up their shared library search paths or use rpath.

Uh, libpq is loaded the same way as any other shared library, no? We're
not talking the libs that are loaded in the backend here, just libpq.dll
as linked to the frontend.

I think that if we can't get a version bump, we're going to have to go
back to storing the DLL file inside the application directory. It means
that we intall 4-5 copies of the DLL file every time, and also that
everybody who wants to run a pgsql program on his machine will have to
copy the DLL file into that programs directory. But that will also solve
this problem. Not very nice, but doable.

//Magnus