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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
