Re: RFC: PostgreSQL Add-On Network - Mailing list pgsql-hackers

> 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