On Fri, May 25, 2007 at 12:59:25PM -0500, Ron Johnson wrote:
> Except that seemingly "boutique" features can be road-blocks to
> implementing projects, which means that you never hear from them.
Yes. That's a risk that free software projects take, alas. If you
can't force your users to tell you what they're doing, then you can't
be sure you have the right picture of what they're doing.
> 1. transaction failure on statement failure[0], and
I personally regard that as a feature, not a bug, so I'd be opposed
to changing it.
> 2. single-threaded backups[1].
This one has always seemed like a nasty limitation to me, but given
the desire (which you have, apparently) to get transaction-bounds
consistency and the design of postgres, I don't see an easy path to
fixing this.
Something that is important to note, however, is that a group of
users who have enough of a desire for a feature that they code it up,
offer to support it, and make sure it gets reviewed (this one is
important!) are going to have an easier time of it. What this means
is that users need to dedicate resources to things that aren't
obviously in their own immediate interests, like patch review, so
that when later they say, "This patch works," there is a stronger
probability the community will take seriously their claims that the
patch works correctly. Free software never comes without cost, and
this is one of them.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Information security isn't a technological problem. It's an economics
problem.
--Bruce Schneier
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
