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

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