Re: Storing images in PostgreSQL databases (again)

"Leonel Nunez" <lnunez(at)enelserver(dot)com> wrote:
>
> > If the database had built-in functions to manipulate images (make a
> > thumbnail, add text ont it.., make a montage of two pictures) and I could
> > write something like
> > select thumbnail(image_field, 100, 100) from images_table
> > that would be a good reason to go the db route versus the filesystem
> > route.

<snip>

> With Python and the python imaging library you can do this :
>
> image is a bytea field
>
> curs = conn.cursor ()
> curs.execute( "select image from images where name = %s" ,(thename, ))
> row = curs.fetchone()
> if row:
> im = Image.open (StringIO.StringIO(row[0]))
> im.thumbnail (160,120 )
> imagetmp = StringIO.StringIO()
> im.save ( imagetmp , "JPEG")
> print ("Content-type: image/jpeg\n\n")
> print ( imagetmp.getvalue())

I think part of the point, which you missed, is the convenience of having
the thumbnailing as part of the SQL language by making it a stored
procedure.

I did a presentation for WPLUG not too long ago where I created C
functions in Postgres compiled against the GSOAP library that allowed
you to make simple SOAP calls in SQL within PostgreSQL. Neat stuff.

The problem with creating those kinds of functions is the CPU overhead.
We'll be generating the thumbnails and storing them in a "thumbnail"
field in the record, so we don't have to regenerate the thumbnail each
time it's needed.

BTW: our reason for keeping the thumbnails in fields is so they can be
replicated with Slony along with the rest of the database.

--
Bill Moran

We meddle. People don't like to be meddled with. We tell them what to do,
what to think. Don't run, don't walk. We're in their homes and in their
heads and we haven't the right.

River Tam