Dave, > Whilst the aim is a noble one, glossing over 'it won't work on > Windows' which is by far our most popular platform these days seems > incredibly short sighted, and liable to lead to an endless stream of > 'why doesn't this work' questions. It also does the module authors no > favours, by excluding 50%+ of their potential audience, and frankly, > isn't the way this project generally works.
But why is that *this* project's job to solve? It's already the case that contrib modules (or PostgreSQL) are not buildable on Windows in an automated fashion. And that Windows does not ship with developer tools. That's not PGAN's fault. > We have discussed this sort of facility at previous developer > meetings, and as I recall came to the conclusion that we need to have > the ability to distribute pre-built binaries, not just source code as > virtually no Windows users are ever going to have a build environment > setup. Similarly, neither are Mac users, if they didn't install XCode. Binary distributions are a good idea, for v2+. The problem with requiring that is then you're effectively requiring every module author, or a well-funded 3rd party, to have a huge build farm capable of building binaries for a wide variety of platforms and PostgresQL versions. Requiring that from the outset is a good way to ensure that nobody *ever* builds an extension management platform. If someone is available to provide that build platform, then it's a different story, but I don't know of anyone with those resources right now. It's *already* the case that Windows users have no access to the temporal, prefix or pgmemcache projects without Visual C++ and some jiggery-pokery. How does PGAN make them worse off? > We also discussed extension management at the DBMS level, which I > believe Dimitri was working on in his spare time. You should look at > what he's been doing. This is designed to be complimentary to Dimitri's project, if you read the wiki page. > Finally, don't write the client in Perl. Again, that's of no use to > most Windows users. C will work on all platforms from the outset, with > no dependencies required. Of course, the server side doesn't matter. It would make sense to build a C version when the other issues with supporting Windows are solved. At that point, the specification for the client should be well-worn enough to make doing the C version not a halt to further development. Until then, it doesn't matter. What I'm getting from your e-mail, Dave, is "If it doesn't solve all problems for everyone in the world from Day 1, it's not worth doing." It's my experience that the way to get OSS software that works is to build a little bit at a time, each delivery of which is useful to some people and solves some problems. Projects which attempt to paint the whole world never get anywhere. David's proposal is designed to be something which he can get done *this year*, possibly before 8.5 is released, and be built on later. It'll be useful to a substantial number of our users, and will be an improvement on what we have now. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
