Tom Lane wrote: > The patch queue is by definition transient --- nobody particularly cares > about what its past state was, as shown by the fact that you've gotten > along for years with an implementation that's incapable of recalling > past state. (Now I do like the idea that a wiki-based patch queue would > retain some history, but I'm not expecting that it'll archive every > change indefinitely.) > > The right way to think about and design the patch queue is as a changing > index into the archives. One of the things I seriously dislike about > your current implementation is that it ignores the archives. You've > whacked us around two or three times this month developing "permanent" > and then "really permanent" URLs, but that whole thing is wrong from the > get-go. You are not the keeper of the project's historical record. > The patch queue should be trafficking in URLs that do point into the > historical record.
Sure, it would be nice if an email link could jump right into the archives, but until we have a way to get to the archives via a message-id, I know of know way to automate that. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
