Hello, In a possible moment of insanity, in
<http://archives.postgresql.org/pgsql-hackers/2006-09/msg00579.php> I volunteered to try to help solve a problem Tom Lane noted: "The hard part of this problem is finding a convenient way to capture status data out of the community's conversations." I observed that companies who do this well actually employ people to do that sort of thing, and that this might be a way for code morons like yours truly to make a contribution to development. I've been struggling since then, trying to figure out where to start. There are a _lot_ of discussions on -hackers, and many of them are blind alleys. Moreover, I can't summarise everything, I don't think, and still make any of those summaries sufficiently detailed to allow them to be useful. So I have a proposal. I was thinking of tracking 3 or 4 such discussions in the next release cycle, as a kind of proof of concept. I'm willing to do that, but I'd need guidance from those who are trying to produce a complicated feature, telling me that they need the support. Therefore, if someone involved in some such discussion pokes me saying, "Follow this thread, please", I'll follow the thread in question (as well as follow-up discussions that come of it), and produce regular (weekly?) summaries of what I take to be the state of the collective mind, until such time as the code supporting the feature is checked in and agreed to. Then, at release time, the developers can evaluate whether the tracking produced few surprises at the end (and, perhaps, less thrash), or whether the experiment did not provide any benefit. If it does, we can see whether we can make this sort of thing scale by adding some additional volunteers to do a similar job in future. Does that seem worth doing? A -- Andrew Sullivan | [EMAIL PROTECTED] "The year's penultimate month" is not in truth a good way of saying November. --H.W. Fowler ---------------------------(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
