| From: | David Helgason <david(at)uti(dot)is> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: nonblocking libpq large object access? |
| Date: | 2004-02-15 18:49:04 |
| Message-ID: | A0E4FD60-5FE7-11D8-B245-000A9566DA8A@uti.is |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 15. feb 2004, at 18:18, Tom Lane wrote:
> A workaround you could think about is invoking the LO functions via
> ordinary SELECT commands, ignoring libpq's LO API altogether. This
> would have been rather painful in pre-7.4 releases since you'd have
> to be willing to deal with quoting and dequoting "bytea" values, but
> as of 7.4 you could use PQsendQueryParams() and specify binary format
> for the bytea inputs and results.
I think I'll go down that road provided it's not a performance killer.
I'll also be considering using a custom perl-socket-server system I
implemented for kicks (it's put up at
http://uti.is/david/320_maintserver_procs.sql, BSD license). It does
gzip of the steam for free, which is a win.
d.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adam Ruth | 2004-02-15 19:32:28 | Re: PostgreSQL Indexing versus MySQL |
| Previous Message | Tom Lane | 2004-02-15 17:18:48 | Re: nonblocking libpq large object access? |