Re: Large objects in web applications

Where exactly is lo_read ?

test=# \df+ lo_
List of functions
Result | Function | Arguments | Owner | Language | Source | Description
---------+-----------+---------------------------+-------+----------+-----------+-----------------------------
integer | lo_close | integer | pgsql | internal | lo_close | large object close
oid | lo_creat | integer | pgsql | internal | lo_creat | large object create
integer | lo_export | oid, text | pgsql | internal | lo_export | large object export
oid | lo_import | text | pgsql | internal | lo_import | large object import
integer | lo_lseek | integer, integer, integer | pgsql | internal | lo_lseek | large object seek
integer | lo_open | oid, integer | pgsql | internal | lo_open | large object open
integer | lo_tell | integer | pgsql | internal | lo_tell | large object position
integer | lo_unlink | oid | pgsql | internal | lo_unlink | large object unlink(delete)
(8 rows)

:-/

TIA,
thalis

On Tue, 26 Jun 2001, Tom Lane wrote:

> wsheldah(at)lexmark(dot)com writes:
> > Has there been any substantial change in the way large objects are
> > handled with the coming of 7.1 and the expanded row size limit?
>
> No change in the API (but 7.1 is more efficient under the hood).
>
> > Assuming things haven't changed for large objects, it appears that to display an
> > image, I'll need to:
> > 1. select the image from postgresql, using lo_export() to save it to a uniquely
> > named temp file (to avoid conflicts with other users).
>
> If you just need to read the data, lo_export to a file and read the file
> is certainly the hard way. Use lo_open/lo_read.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>