Re: patch for spelling mistake - Mailing list pgsql-patches
From | Neil Conway |
---|---|
Subject | Re: patch for spelling mistake |
Date | |
Msg-id | 20010710215627.C727@klamath.dyndns.org Whole thread Raw |
In response to | Re: patch for spelling mistake (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
RE: patch for spelling mistake
Re: patch for spelling mistake Re: patch for spelling mistake |
List | pgsql-patches |
On Tue, Jul 10, 2001 at 08:58:30PM -0400, Bruce Momjian wrote: > > nconway@klamath.dyndns.org (Neil Conway) writes: > > > I think I made the patch properly; from the root of the 'pgsql' > > > CVS module, apply with: patch -p0 < patchfile. > > > > diff -c output is preferred. A plain diff such as you have here has too > > little context to be safe to apply (if someone else has edited the file > > since the version you diffed from, a plain diff patch is much too likely > > to be applied incorrectly). > > Tom is right, diff -c is best, though in the patch you applied, there is > no chance for error so I can accept it. You have unique previous text > for each change. Sorry about that -- and thanks for the tip (Tom & Bruce). I've remade the patch using the make_diff tools -- that seems to produce the preferred the format. The updated patch is below. I'm going to add this info to the Developer's FAQ, but it seems like there are 2 copies -- one plaintext and one HTML: it seems as though they are updated simultaneously (according to the CVS logs anyway). Which version should I make changes to? Both? Are they generated from a single source document somewhere? Cheers, Neil *** ./src/backend/commands/cluster.c.orig Tue Jul 10 21:34:14 2001 --- ./src/backend/commands/cluster.c Tue Jul 10 21:34:30 2001 *************** *** 45,57 **** * cluster * * STILL TO DO: ! * Create a list of all the other indicies on this relation. Because * the cluster will wreck all the tids, I'll need to destroy bogus ! * indicies. The user will have to re-create them. Not nice, but * I'm not a nice guy. The alternative is to try some kind of post * destroy re-build. This may be possible. I'll check out what the * index create functiond want in the way of paramaters. On the other ! * hand, re-creating n indicies may blow out the space. */ void cluster(char *oldrelname, char *oldindexname) --- 45,57 ---- * cluster * * STILL TO DO: ! * Create a list of all the other indexes on this relation. Because * the cluster will wreck all the tids, I'll need to destroy bogus ! * indexes. The user will have to re-create them. Not nice, but * I'm not a nice guy. The alternative is to try some kind of post * destroy re-build. This may be possible. I'll check out what the * index create functiond want in the way of paramaters. On the other ! * hand, re-creating n indexes may blow out the space. */ void cluster(char *oldrelname, char *oldindexname)
pgsql-patches by date: