Re: Load Image File From PostgreSQL DB

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Julius Tuskenis *EXTERN*" <julius(dot)tuskenis(at)gmail(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Load Image File From PostgreSQL DB
Date: 2008-12-31 09:17:26
Message-ID: D960CB61B694CF459DCFB4B0128514C202EA75C7@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Please don't top post.

Julius Tuskenis wrote:
>> Large Objects (http://www.postgresql.org/docs/current/static/largeobjects.html)
>> use OID columns, and they work fine for storing binary data like images.
>
> In the article you provided it is said that "The return value is the OID
> that was assigned to the new large object..." (function Oid
> lo_creat(PGconn *conn, int mode);). That means that not the large object
> is stored in OID field - its just the reference to it.

Yes, that's true.
You'll have to use the large object API to access the data.
All I wanted to point out is that while you cannot store binary data
*IN* an OID column, you can very well do so *USING* an OID column.

> Any way I find it much easier to get a relatively small blob in a result
> set and not directly using lo_read function, because in delphi zeos
> components does work with libpq, so theres no need to bypass them?

Yes, it is easier, and probably in most cases better, to use bytea.
I think that large objects are preferrable ony if
a) you need to store more than 1GB or
b) you need the operations that only large objects provide, like
reading out only part of the binary data.

I don't quite understand what you wrote about lo_read and libpq,
because libpq provides lo_open.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Julius Tuskenis 2008-12-31 09:36:32 Re: Load Image File From PostgreSQL DB
Previous Message Albe Laurenz 2008-12-31 09:08:30 Re: return X number of refcursors from a function