Re: Version numbers on libpq.dll
От | Magnus Hagander |
---|---|
Тема | Re: Version numbers on libpq.dll |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE47638E@algol.sollentuna.se обсуждение исходный текст |
Ответ на | Version numbers on libpq.dll ("Magnus Hagander" <mha@sollentuna.net>) |
Ответы |
Re: Version numbers on libpq.dll
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers-win32 |
>> >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
В списке pgsql-hackers-win32 по дате отправления: