Re: Commit fest?

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Commit fest?
Date: 2008-03-17 03:45:56
Message-ID: Pine.GSO.4.64.0803162327270.14769@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 16 Mar 2008, Bruce Momjian wrote:

> Oh, what I would really like is to be able to pull up
> archives.postgresql.org emails based on message id so I can link to the
> entire thread. Unfortunately, it doesn't work there, nor does Google or
> any of the other Postgres email archive sites.

This is something I've been looking into my own organization. The message
ids are at the start of the archive web pages. For example your e-mail
here I'm replying to begins like this if you look at the page source:

http://archives.postgresql.org/pgsql-hackers/2008-03/msg00554.php
<!-- MHonArc v2.6.16 -->
<!--X-Subject: Re: Commit fest? -->
<!--X-From-R13: Pehpr [bzwvna <oehprNzbzwvna.hf> -->
<!--X-Date: Sun, 16 Mar 2008 23:19:33 &#45;0300 (ADT) -->
<!--X-Message-Id: 200803170219(dot)m2H2JRQ11863(at)momjian(dot)us -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 20681(dot)1205719990(at)sss(dot)pgh(dot)pa(dot)us -->
<!--X-Head-End-->

I was thinking of writing something that scraped the archives building a
lookup table out of this information. What would be nice is if the
X-Message-Id and X-Reference were both put into the regular HTML for
future archived messages so that it's more likely tools like Google could
search based on them. A brief glance at the MHonArc documentation
suggests that could be run to re-covert any existing messages that are
still available in order to add to those even.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-03-17 03:59:41 Remove hacks for old bad qsort() implementations?
Previous Message Cristian Gafton 2008-03-17 03:35:54 Re: Single table forcing sequential scans on query plans