Skip site navigation (1) Skip section navigation (2)

Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
Date: 2013-01-09 16:27:46
Message-ID: 25646.1357748866@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2013-01-09 13:34:12 +0100, Magnus Hagander wrote:
>>> Am I the only one who finds this way of posting patches really annoying?

>> Well, I unsurprisingly don't ;)

> Yeah, that's not surprising :)

I'm with Magnus.  This is seriously annoying, especially when the
"discussion" thread has a title not closely related to the "patch"
emails.  (It doesn't help any that the list server doesn't manage to
deliver the emails in order, at least not to me --- more often than
not, they're spread out over a few minutes and interleaved with other
messages.)

I also don't find the argument that the commit messages are a substitute
for patch descriptions to be worth anything.  Commit messages are, or
should be, for a different audience: they are for whoever writes the
release notes, or for historical purposes when someone is looking for
"which patches touched a particular area?".  That's not the same as
explaining/justifying the patch for review purposes.  Reviewers want
a lot more depth than is appropriate in a commit message.  (TBH, I rarely
use any submitter's proposed commit message anyway, but that's just me.)

I'd prefer posting a single message with the discussion and the
patch(es).  If you think it's helpful to split a patch into separate
parts for reviewing, add multiple attachments.  But my experience is
that such separation isn't nearly as useful as you seem to think.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-09 16:37:46
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous:From: Tom LaneDate: 2013-01-09 16:00:01
Subject: Re: PL/perl should fail on configure, not make

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group