[masklinn]

> 2) There was an effective row size limit of 8K over the whole row which worked against people who wrote forum software and were (ugh) storing binaries in the database.

Could you not just use the dedicated TEXT or BLOB type for that kind of stuff, and store them out-of-row? (yes, would probably have been even slower)

[pilif]

Nope. There was blob-support, but that relied on special library functions to extract the data to a file which you'd then have to manually read.

Of course this also means that you couldn't search in these fields or do anything else you'd do directly on the database.

TOAST tables were added in 7.1 AFAIK which lifted that limit and allowed for arbitrary sized rows by moving the big fields away into their own storage.

The old functionality is still there (http://www.postgresql.org/docs/9.0/interactive/largeobjects....) though I totally failed and still fail to see any practical use.

[masklinn]

> Nope. There was blob-support, but that relied on special library functions to extract the data to a file which you'd then have to manually read.

OK.

> The old functionality is still there (http://www.postgresql.org/docs/9.0/interactive/largeobjects....) though I totally failed and still fail to see any practical use.

Memory constraints maybe? That's about the only justification I could see for using that over bytea: if you store single binary objects in the GB+ range, you may want to interact with them as streams.