Hello,
I would like to receive comments/suggestions about this project:
http://github.com/drotiro/postpic.
In short, it's an extension that enables image processing within the database, adding a new type (image) and several functions.
The SQL and Java interfaces are documented on the project's wiki, so I'm not talking about these here, but instead present some detail on the datatype's implementation.
The image is represented by a struct containing some attributes (dimensions, some exif tag: shoot date, exposure time...) and a large object holding the actual image data.
The idea is to have attributes stored directly to allow for efficient searching, while the large object seemed a reasonable choice to store the possibly large image data (what are the LOBs for?).
With the current large objects implementation, when a new lo is created it "lives" in the pg_largeobjects table, until someone calls lo_unlink on it. In my case: I create the lo on behalf of the user, then store its oid in the image's internal representation. At this point, the image can be inserted in a table, processed and so on, but when it gets deleted the corresponding lo remains dangling, unless someone or something (eg. a trigger) takes care on destroying it.
Is there a way of placing some kind of hook on an object's deletion? A clean way to do a reference counting on large objects?
To avoid polluting pg_largeobjects, almost all of the image processing functions in PostPic return a 'temporary_image' object, which is just an alias on bytea. (Btw: I defined it using a DOMAIN. A better way?). Temporary images can be converted back to images when needed via a cast (often there is a variant of the function doing this automatically).
Thanks in advance for your suggestions and contribution,
Domenico.