Обсуждение: nonblocking libpq large object access?

Поиск
Список
Период
Сортировка

nonblocking libpq large object access?

От
David Helgason
Дата:
I was just wondering whether this was either:
    - supported, or
    - doable, either
        - using the normal poll-read-done? loop
        - a settable timeout

It would be awfully nice.

David Helgason,
Over the Edge Entertainments


Re: nonblocking libpq large object access?

От
Tom Lane
Дата:
David Helgason <david@uti.is> writes:
> I was just wondering whether this was either:
>     - supported, or
>     - doable,

AFAIK no one has tried to make it work.  Offhand it seems you'd need
to modify the API for libpq's LO operations in order to handle this.

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.

            regards, tom lane

Re: nonblocking libpq large object access?

От
David Helgason
Дата:
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.