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

On Thu, Jan 7, 2010 at 9:22 PM, Josh Berkus <josh@agliodbs.com> wrote:
> 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?

Because if we (PostgreSQL) are going to support this effort, then it
should not ignore such a huge percentage of our installation base.

> 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.

No. But that's why we built binaries for people to use. That's pretty
much my point.

> 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.

No, I'm suggesting the mechanism needs to support source and binary
distribution. For most *nix users, source will be fine. For Windows
binaries are required.

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.

>> 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.

So you have to rewrite the code. Seems like a waste of effort.

> 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."

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'.


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com