| From: | Chris Browne <cbbrowne(at)acm(dot)org> | 
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: RFC: PostgreSQL Add-On Network | 
| Date: | 2010-01-13 20:18:22 | 
| Message-ID: | 87637521yp.fsf@dba2.int.libertyrms.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
robertmhaas(at)gmail(dot)com (Robert Haas) writes:
> On Fri, Jan 8, 2010 at 10:12 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>> I have long spoken against making Windows a second class citizen. But I
>>> don't think David is going to do that (and I'll hound him if he does). But
>>> that doesn't mean it has to be fully supported from day one.
>>
>> I'm not saying it should be supported from day 1, but I think the
>> initial plan will make it very difficult to add Windows support later
>> without a great deal of rewriting/redesign. It's lack of forward
>> planning I was objecting to.
>
> I personally suspect that the client is not the most important part of
> this project.  I think the value of CPAN is for searching, more than
> auto-installing.  Personally, I never use the auto-install feature
> because I always want more control than you get that way.  I just use
> the site to find possible modules and browse the docs, and then if I
> find something I like I check with I can pull it from the Red Hat
> repos with rpm, and if not I download it and look it over to see if it
> DWIW, and then if so I usually make a private SRPM for it and install
> from that.  I'd be happy if we just had a good search-and-download
> site.
If "PGAN" leads to us having:
 a) A database containing a useful set of metadata about a large set of
    extensions, and
 b) A way for PostgreSQL developers and binary distribution makers (who
    *do* have GCC / XCode / MingW / Visual Studio / ... available to
    them) to easily:
      - build
      - test
      - try out
      - think about how to package
    that large set of extensions
then we've got a Big Win of the same sort as CPAN, Ruby Gems, and PyPI.
It does NOT need to include installers for every known kind of computer;
that is a *second* problem, which actually requires a series of
solutions for:
 a) Fedora
 b) Debian (hence derivatives like Ubuntu)
 c) BSD Ports
 d) Yes, Windows
 e) I think Solaris has something new for packaging...
If David gets it to the point where it's easy to build and install
extensions into a PostgreSQL installation, then turning that into
packages for specific targets should be a not-insurmountable problem
that may be treated separately.
> That having been said, we should consider our filesystem layout
> carefully however to make sure that if we want to provide things like
> Windows installers in the future, we have a clean way to do that.
If the extensions get installed in a way that is "scalable" in the sense
that it's not a particularly big deal to write a script that pulls 250
extensions and installs them on a particular host for a particular PG
installation, then I'd think that the exercise has been a successful
one.
That leads, naturally enough, to an "Extension BuildFarm" :-).
I'd be somewhat surprised if the use of Windows was a material factor in
the matter.
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www3.sympatico.ca/cbbrowne/postgresql.html
"Laugh-a while you can, Monkey Boy."  -- Dr. Lizardo - Buckaroo Banzai
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2010-01-13 20:37:24 | Re: Bloom index | 
| Previous Message | Joshua D. Drake | 2010-01-13 20:12:05 | Re: plpython3 |