From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: PostgreSQL Add-On Network |
Date: | 2010-01-07 21:31:53 |
Message-ID: | 937d27e11001071331m516a0db9m4a2cd9a7828ca0f1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 7, 2010 at 9:22 PM, Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2010-01-07 21:34:47 | Re: RFC: PostgreSQL Add-On Network |
Previous Message | Greg Smith | 2010-01-07 21:31:14 | Re: pg.dropped |