PG 7.1 can back up the built-in large object type. While there are now infinite-length rows there's no binary interface to such rows, so they're really best thought of as being "clobs".
So ... the current large-object hack in the PG driver has a bit of life in it. The efficiency hit doesn't seem to be that bad compared to what you'd get if you didn't need the driver hack but still stored the binary data in the database.
Here's a filesystem vs. db pro-con argument:
In favor of the filesystem:
1. More efficient uploading and downloading.
In favor of the database:
1. The current driver hack gives you pg_dumpable tables. So your
system backup strategy is easy - just dump the database and keep your script sources in cvs on another machine that's also backed up.
If you put blob data in files, you need to backup them as well as your database, and guaranteeing consistency is problematic.
So I've been thinking about the possibility of supporting both in the ACS 4x content repository. The object structure should make it easy to do so. The notion is that a site that expects to do relatively little with files, portraits, photos etc might prefer the "all I need is pg_dump to make a consistent backup" philosophy that come with the in-database storage strategy.
On the other hand, there's no doubt that any site that does a high volume of file upload/downloads will want an in-filesystem strategy, due to the much higher efficiency of that approach.
