On Thu, Apr 24, 2014 at 9:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Apr 24, 2014 at 9:50 AM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> On Thu, Apr 24, 2014 at 8:27 AM, Magnus Hagander <magnus@hagander.net>
>> wrote:
>> > On Thu, Apr 24, 2014 at 7:54 AM, Michael Paquier
>> > <michael.paquier@gmail.com>
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> A colleague of mine pointed out that the file version is missing in a
>> >> couple of dll and exe files when building on windows using the
>> >> community scripts in src/tools/msvc. After having a closer look, I
>> >> noticed that a *lot* of files are missing the shot:
>> >> - all the exe/dll in contrib/
>> >> - dll of PL languages (perl, python, tcl, pgsql)
>> >> - libpqwalreceiver, snowball
>> >> - ecpg stuff
>> >> - regression and isolation test stuff
>> >> - conversion_procs thingies
>> >> Having a version number associated to a build is important for all
>> >> companies creating builds of Postgres on Windows, so it would be good
>> >> to have the patch attached applied and back-patched.
>> >>
>> >
>> > At least some fo that is intentional - things that are considered
>> > "internal"
>> > were not given a version resource intentionally. E.g. the
>> > conversion_procs
>> > is very intentional.
>>
>> Why? Version resources are kinda handy for installers to reliably
>> figure out whether or not something should be upgraded.
>
>
> I think the general argument was "maintenance overhead". This was back
> before the 8.0 release, so my memory is somewhat sketchy :)
>
> Which also means of course that we can reconsider that decision. But if we
> do, we need to support it equally in mingw and msvc.
Well it's pretty darn close to zero maintenance isn't it? We don't
even have to maintain rc files with the proposed patch (if my
extremely weak perl-fu is reading the code correctly).
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
