No limits on historic attachments

An attachment can have an unlimited number of versions, there are no constraints around this and performance suffers when there are too many versions. Specific instances where there should be some sort of limit:

• When Confluence displays a file's history in the Attachments view or the Attachments macro, the entire history is always displayed.
• When getPreviousVersions is called on the AttachmentManager there is no way to say "only X" and no limit is enforced.

Additionally, the relationship between an attachment and its histories is not cached, so there can be unnecessary hits to the database. There is an "Attachments Version" cache defined, but I can't see where anything would ever get written to it.

This is the case in Confluence 3.4, and I suspect that with the possible exception of caching, this has always been an issue. Obviously having many versions of the same attachment is something that usually doesn't occur.