Re: Storing images as BYTEA or large objects
От | Koen Vermeer |
---|---|
Тема | Re: Storing images as BYTEA or large objects |
Дата | |
Msg-id | 1202910697.8863.7.camel@localhost обсуждение исходный текст |
Ответ на | Re: Storing images as BYTEA or large objects (Peter Wilson <petew@yellowhawk.co.uk>) |
Ответы |
Re: Storing images as BYTEA or large objects
Re: Storing images as BYTEA or large objects |
Список | 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
В списке pgsql-general по дате отправления: