Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, David Fetter <david(at)fetter(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Kenneth Marshall <ktm(at)rice(dot)edu>, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>
Subject: Re: [PATCH] cleanup hashindex for pg_migrator hashindex compat mode (for 8.4)
Date: 2009-05-26 14:09:01
Message-ID: 11264.1243346941@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> writes:
> I'll repeat my suggestion that everyone poo-pooed: we can have the
> mail list filters recognize patches, run filterdiff on them with our
> prefered options, and attach the result as an additional attachment
> (or link to some web directory).

The argument that was made at the developer meeting is that the
preferred way of working will be to apply the submitted patch in one's
local git repository, and then do any needed editorialization as a
second patch on top of it. So the critical need as I see it is to be
able to see a -c version of a patch-in-progress (ie, diff current
working state versus some previous committed state). Readability of the
patch as-submitted is useful for quick eyeball checks, but I think all
serious reviewing is going to be done on local copies.

> I think this is actually all a red herring since it's pretty easy for
> the reviewer to run filterdiff anyways.

I don't trust filterdiff one bit :-(

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-05-26 14:14:54 Re: problem with plural-forms
Previous Message Alvaro Herrera 2009-05-26 14:05:35 Re: problem with plural-forms