Instead of a patch it might be easier to submit the new columns as a
perl script or sed command. We do something like that to make merging
pg_proc easier.
greg
On 8 Nov 2008, at 01:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David Rowley" <dgrowley@gmail.com> writes:
>> patching file src/include/catalog/pg_proc.h
>> Hunk #4 FAILED at 106.
>> 1 out of 4 hunks FAILED -- saving rejects to file
>> src/include/catalog/pg_proc.h.rej
>
> I imagine you'll find that "hunk #4" covers the entire DATA() body of
> the file :-(. It can't possibly apply cleanly if anyone's added or
> altered pg_proc entries since the patch was made.
>
> What you'd need to do is manually insert proiswfunc = 'f' entries in
> all the existing DATA lines (this is usually not too hard with sed or
> an emacs macro), then add whatever new functions the patch defines.
> Even figuring out the latter from the patch representation can be a
> serious PITA, since they'll be a few lines out of a multi-thousand-
> line
> failed diff hunk.
>
> I'm not sure if Hitoshi is in a position to submit the pg_proc changes
> as two separate diffs --- one to add the new column and a separate one
> to add in the new functions --- but it'd be a lot easier to deal with
> merge issues if he could.
>
> (Now I'll sit back and wait for some fanboy to claim that
> $his_favorite_scm could solve this automatically ...)
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers