On Tue, Apr 26, 2011 at 06:21:21AM -0400, Greg Smith wrote:
> addressed doesn't start with "how can PostgreSQL duplicate the
> Oracle solution to this problem", which is how many of these
> incoming requests for features start. The alternate question of
> "how do you provide something with the same feature set for
> PostgreSQL?" is the more useful one, and it doesn't lead to the same
> solutions. That disconnect is important to address.
But the problem there is a really fundamental one, in that it goes to
the core of how free software gets developed: someone has a problem
that s/he wants fixed.
"The problem" in many of these cases is really, "I know how to do _x_.
How do I do that in Postgres?" If the answer is, "You don't," it
sounds like a missing feature.
In commercial development, this is where product development managers
live. They identify the meaning of the feature request, and then
identify how the actual need (rather than the requested feature) can
be addressed.[1] But in the free software world, of course, that won't
work unless you also have the developer hours to contribute to make
the feature. Moreover, there is a strong preference toward 80/20
answers, because the code will have to be maintained and unless
someone who is pushing for a feature has a record of hanging around to
maintain it, there's good reason to wonder whether the feature will be
supported.
The Postgres community is much better than most at this sort of thing,
of course, but it's hard to compete with commercial development on
refining user experience.
[1] Um, ok, the good ones do this. The bad ones say, "Oh, people want
an animated paper clip," or, "Oh, people want us to extend PDF so that
it's an excellent vector for viruses," or, "Oh, people want high
uptime, so we'll make this multi-node failover thing that blows away
your system if you sneeze wrong," or something like that.
A
--
Andrew Sullivan
ajs@crankycanuck.ca
