<br /><br /><div class="gmail_quote">On Tue, Mar 16, 2010 at 1:04 PM, Albe Laurenz <span dir="ltr"><<a
href="mailto:laurenz.albe@wien.gv.at">laurenz.albe@wien.gv.at</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="margin:0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div
class="im">DomenicoRotiroti wrote:<br /> > I would like to receive comments/suggestions about this<br /> >
project:<a href="http://github.com/drotiro/postpic" target="_blank">http://github.com/drotiro/postpic</a>.<br />
><br/> > In short, it's an extension that enables image processing<br /> > within the database, adding a new
type(image) and several functions.<br /> ><br /></div><div class="im">> The image is represented by a struct
containingsome<br /> > attributes (dimensions, some exif tag: shoot date, exposure<br /> > time...) and a large
objectholding the actual image data.<br /> > The idea is to have attributes stored directly to allow for<br /> >
efficientsearching, while the large object seemed a<br /> > reasonable choice to store the possibly large image
data<br/> > (what are the LOBs for?).<br /> > With the current large objects implementation, when a new lo<br />
>is created it "lives" in the pg_largeobjects table, until<br /> > someone calls lo_unlink on it. In my case: I
createthe lo on<br /> > behalf of the user, then store its oid in the image's<br /> > internal representation. At
thispoint, the image can be<br /> > inserted in a table, processed and so on, but when it gets<br /> > deleted
thecorresponding lo remains dangling, unless someone<br /> > or something (eg. a trigger) takes care on destroying
it.<br/> > Is there a way of placing some kind of hook on an object's<br /> > deletion? A clean way to do a
referencecounting on large objects?<br /><br /></div>If you want a system with reference counts, you'd probably have<br
/>to write it yourself using triggers.<br /><br /> There's the "vacuumlo" contrib module that removes orphaned<br
/><divclass="im">large objects.<br /><br /> > To avoid polluting pg_largeobjects, almost all of the image<br /> >
processingfunctions in PostPic return a 'temporary_image'<br /> > object, which is just an alias on bytea. (Btw: I
definedit<br /> > using a DOMAIN. A better way?). Temporary images can be<br /> > converted back to images when
neededvia a cast (often there<br /> > is a variant of the function doing this automatically).<br /><br /></div>Why
don'tyou use bytea instead of large objects in the database?<br /> That way you won't have to worry about orphaned
largeobjects,<br /> and you don't have to convert to bytea upon retrieval.<br /><br /> Yours,<br /><font
color="#888888">LaurenzAlbe<br /></font></blockquote></div><br />