From: | Domenico Rotiroti <drotiro(at)tiscali(dot)it> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | [RFC] Comments on PostPic project - Repost |
Date: | 2010-03-16 08:37:42 |
Message-ID: | 11f931f91003160137w3b6a7af6p175b451f2602138d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I had no answer from pgsql-general, so I'm reposting here.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-03-16 09:02:07 | Re: Getting to beta1 |
Previous Message | Takahiro Itagaki | 2010-03-16 03:09:14 | Re: Ragged latency log data in multi-threaded pgbench |