From: | Koen Vermeer <koen(at)vermeer(dot)tv> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Storing images as BYTEA or large objects |
Date: | 2008-02-13 13:51:36 |
Message-ID: | 1202910697.8863.7.camel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2008-02-13 at 09:35 +0000, Peter Wilson wrote:
> I've used both methods. The only real problem is that none of the
> trigger based replication schemes
> such as Slony can't deal with large objects.
I can live with that for now. If the project ever gets that big, I
probably need to rethink some design choices anyway.
> Depending on what programming language you're using you do *not* need to
> escape the binary
> data for BYTEA. Using libpq from C/C++ you can pass the binary data
> straight into the database. See
> PQexecParams :
> http://www.postgresql.org/docs/8.3/interactive/libpq-exec.html#LIBPQ-EXEC-MAIN
> We use server-side JavaScript here that makes use of that interface so I
> can take an image directly
> from the web-server and move it into the database with no escape overhead.
Ah, I see, that seems to be a better way indeed. I can probably do
something like that with PHP as well.
> My preference : if I don't need the file-like interface to large objects
> I'd use BYTEA every time.
Right, so that basically means that when 'large objects' are files,
which should be saved and restored as a whole, it may be more natural to
use the large objects. I guess that applies to some uses of media
storage (music, photos, video).
The large-objects-are-actually-files thing applies to my situation, so
unless there is some 'large objects are / will be deprecated' argument,
I guess I stick with large objects.
Thanks!
Koen
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-02-13 14:15:15 | Re: Storing images as BYTEA or large objects |
Previous Message | Alvaro Herrera | 2008-02-13 13:45:32 | Re: Storing images as BYTEA or large objects |