If you want to get fancy you can create a "user defined type" for each type of attachment. A very vanilla implementation would just make it a little easier to figure out what you have but a RECORD type would allow you to cache "interesting" information (e.g., the size of an image in pixels) and a full implementation in C, java, etc., could compute that "interesting" information from the raw data and even perform different types of manipulation. E.g., you could have a "user defined function" that rescales the image to a desired size.
The downsides are that few frameworks understand UDT. That's not a problem if you're writing everything by hand or are able to use hand-written code for specific functionality but could be a problem if you're trying to do everything via a framework.
Another potential downside is if you don't host your own instance, e.g., you're using an AWS RDS instance. They won't allow you to use "C" extensions. (You can still use pure SQL extensions.)
Finally if you want to be generic - you want "attachments" but don't want to require explicit types, you can either use a generic UDT or create a polymorphic one where the DB sees the UDT but you have UDF that allow you to cast the type to a specific format if possible.