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.
