> Building them is no problem - authors can easily use EC2 for which we > have an AMI pre-configured for next to no cost, can build on their own > platform, on a community provided system, or get a friend to do it.
So any module author, in order to submit any module, would be required to build binaries for 8-12 platforms covering up to 5 PostgreSQL versions (i.e. 30-70 different binaries)? At their own cost? Seems like a good way to not get any contributions at all. For that matter, Andrew just pointed out to me (corrected me, actually) on IRC that if a Windows user has MSVC or Mingw installed, it should be no problem supporting them. So what you're asking has nothing to do with Windows users, but is a more general "we want support for users who don't have a compiler installed". That's a different problem -- and one which the One-click installer or Stackbuilder should probably solve rather than PGAN. > No. The essence is, 'If you're going to do it in a way that will never > work for maybe 50% or more of PostgreSQL installations, then you have > fundamental design issues to overcome'. Again, that's the wrong attitude. You're saying "If it doesn't work for 100% of Windows users from Day 1, it won't ever work for them." By that logic, we should have held back version 7.4 until the windows port was done, dammit! And we shouldn't have released until it worked with Visual C++. Even if it meant releasing in 2007. And we shouldn't have released PITR until it supported HS. And we shouldn't be releasing 8.5 without Win64 support. The reason I'm harping on this is this list has a real tendency to reject simple solutions which allow room for growth in favor of overcomplicated world-spanning specifications which will never be implemented. Despite the fact that we only have some notable features because we took the simple approach: partitioning, PITR, the Buildfarm, CommitFests. And that features which there is no obvious way to implement in small steps incrementally (Windows Port, HS, HOT) are huge development problems for us. This list *also* has a real tendency to have an incredible negative attitude, which *you* are currently expressing. The constructive way for you to approach this would have been to say "I think that the general idea has merit, but that putting off Windows support is a mistake. What about supporting binary distribution at the outset? And coding the client in C?" Instead, you said "this doesn't solve problems A, B, and C, so it's stupid." Building a simple solution which doesn't initially cover all bases but can be steadily improved is a far superior strategy to trying to spec The Perfect Solution before even starting work. And if we want to keep recruiting new contributors, criticism needs to be more constructive. --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
