Andrew Dunstan <andrew@dunslane.net> writes:
> Josh Berkus wrote:
>> I'll admit that I had hopes for it for PR reasons, which
>> is not usually why we make decisions. It would be cool to be the first
>> database system to ship with any implementation of Full Disjunctions, and
>> I can't announce that if it's on pgFoundry.
> I don't see that having it on pgfoundry makes it less announceable. But
> if/when we get support at the SQL level, then we'll *really* have
> something worth announcing.
I think Andrew's first point here is spot-on. We *must* take pgfoundry
seriously as part of the available technology for Postgres. Otherwise
all the effort we've put into building up pgfoundry (and gborg before it)
was a waste of time. Are Perl modules taken less seriously because
they're on CPAN rather than part of the minimal Perl distribution?
No, they're not. That is the model that we've got to strive for,
because the core developers simply haven't got enough cycles to deal
with core Postgres development and the entire kitchen sink as well.
This is not just a matter of core-developer laziness, either. The
concept of a cloud of useful code around a small core is something
I think is absolutely critical to PG's long-term success. We have
a built-in advantage here because of PG's historical commitment to
extensibility. Can you see Oracle, DB2, or MySQL operating that way?
No, you can't, because their core code is not open, or they have a
business need to control everything going on, or both.
We need to *exploit* our ability to support important outside-the-core
projects. Not assume that anything outside core can't be important.
regards, tom lane