One quick and dirty solution could be to implement an hierarchy of directories lead by exact PostgreSQL version and containing patches to apply against.
Something like:

patches/
            8.4.0/
           8.4.1/
          8.4.2/

This would make really easy to find out if the building version requires to be patched and with which files. On the other hand, I suspect some patches could be applied to multiple versions (e.g., 8.4 branch) and therefore the above approach will lead to duplication of patches. Making a patch-chain sounds a little too complicated for, ehm, a shell script, and is probably out of scope for pgenv.
I would propose a "by-version" approach as detailed before, in the case it is fine, please assign the issue and I will submit a proposal.

Yeah, lotta duplication, though. Another approach would be to have a directory with all the patches, and then a lookup table for each version listing the patches that need to be applied. Would be a big table, potentially, but it could be put in a separate file and loaded only when doing a build.

What about a "system V" approach? A single directory with all the patches, and a set of per-version directories with links to the files in the main directory. Will resolve duplication and prevents for having a table, something I believe a script is not so able to work with.
We could also build a per-version, per-os level of directories and links to customize as much as possible the process.

That's not a bad idea, though maybe per-version files listing the required patches would be better, since then we don't have to worry about the portability of symlinks.

Forgot to mention this issue in my pull request, please see #20.

Since #20 has been merged, can we close the ticket or are going to keep open to remind us to add patches in the code base?