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