Horton

Re: Draft release notes complete

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, Alvaro Herrera <alvherre@commandprompt.com>, PeterEisentraut <peter_e@gmx.net>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-05-11T14:37:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Expose track_iotiming information via pg_stat_statements.

  2. Rewrite GiST support code for rangetypes.

  3. Clean up a couple of box gist helper functions.

  4. Replace the "New Linear" GiST split algorithm for boxes and points with a

Bruce Momjian <bruce@momjian.us> writes:
> Let me add that I am concerned about the lack of objectivity in many of
> the suggestions in this thread.  This has prompted me to think that the
> temptation of having names on these release note items is just too
> great, and that the names should be removed.

Er, what?  I have not seen anything in this thread that merits such
an accusation.

> Let me put it this way --- the release notes are read by thousands of
> people.  The benefit individuals gather from their names in the release
> notes is a small part of the overall value provided by the release notes
> to users.  There was a practical need to have names on items in the past
> --- that need is no longer present.

My recollection is that we have been putting the names on the items to
(a) give credit where credit is due, and (b) show that Postgres has a
large and growing development community.  I had never heard the argument
"remember whom to blame for a broken feature" until you raised it
yesterday --- personally, I've always looked in the commit logs if I want
to know something like that.  So I don't see that there's really any
change in the terms of discussion.  It may be that the release notes
aren't the best place for doing either (a) or (b), but I don't agree
that we simply don't need to worry about either anymore.

			regards, tom lane