Thread: Large objects in web applications
Hi, 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? Some old online articles suggested that would change things, but the current docs seem say I still need to use functions like lo_import. 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). 2. Read/load the temp file and send it out to the browser. 3. Delete the temp file Is this conceptually correct? Any pointers to good docs or articles on doing this with perl? I know it's straightforward, but I'd just as soon not reinvent the same mistakes if I can help it. Thanks, Wes
On Tue, 26 Jun 2001 wsheldah@lexmark.com wrote: > > 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? Some old online articles > suggested that would change things, but the current docs seem say I still need > to use functions like lo_import. For large text objects you may use the toast feature in 7.1 where the length of a text field is no longer limited > > 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). > 2. Read/load the temp file and send it out to the browser. > 3. Delete the temp file I do this directly by using the blob_read interface of the DBD::Pg library and then just printing out the blob with the appropriate mimetype. You may refer in the <IMG> tag a script instead of a cooked file. If you like to have an example please contact me directly because this mailing list is not Perl related. Best regards Herbie -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Herbert Liechti http://www.thinx.ch ThinX networked business services Adlergasse 5, CH-4500 Solothurn ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wsheldah@lexmark.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
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@lexmark.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
>
"Thalis A. Kalfigopoulos" <thalis@cs.pitt.edu> writes:
> Where exactly is lo_read ?
In libpq and other interface libraries (ie, it's a client-side function).
regards, tom lane