Tuple limit will be entirely gone in PG 7.1, actually. It works similarly to the large-object kludge I put in the PG driver to let us port things like the file-storage module without rewriting it to store files in the file system rather than the DB (though, of course, Ben later did the sensible thing and rewrote it).
In other words, large columns get shuffled off into an auxiliary table. This implies that retrieving them involves a JOIN operation. The cost of that may well be offset by the fact that selecting the rows to be returned won't require dragging along the lengthy column data (in other words, the long columns are JOINed to the rows returned by the query). And there's built-in compression ala the secret lzText type we've been using in OpenACS.
However, as Roberto points out, the tuple size limit in PG has always been a compile-time option. The PG folk haven't done a good job of making that clear to people, which has led to much of the world believing that the 8KB *default* limit on the length of a tuple was actually a *hard-wired* limit. Which has never been true. The *real* hard-wired limit has always been 32KB. Still fixed, still too short for LOBs, but a lot better than 8KB.
It is arguable that PG would've gotten a lot better press over the years if they'd just made the default blocksize 32KB rather than 8KB!
For instance, Reuven, the OpenACS project recommends compiling with a 16KB blocksize. Combined with the compressed lzText type, this has proven adequate for holding real-world bboard text, etc with truly long stuff like PDF files being stuffed into the db via the long-object hack I wrote into the AOLserver postgres driver.
With PG 7.1, it will be reasonable to run OpenACS with the default 8KB tuple size and the long-object hack will no longer be necessary. Which is truly exciting.
