[RFC] Comments on PostPic project - Repost

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.

Responses

Browse pgsql-hackers by date

  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