"Stephen R. van den Berg" <srb@cuci.nl> writes:
>>A possibly more convincing argument is that with that approach, the
>>connection is completely tied up --- you cannot issue additional
>>database commands based on what you just read, nor pull rows from
>>multiple portals in an interleaved fashion.
>
> Interleaved retrieval using multiple portals is not what most libraries
> support, I'd guess. It can be supported at the application layer using
> multiple cursors, but that works with my approach as well.
>
> In practice, most applications that need that, open multiple
> connections to the same database (I'd think).
Er? There's nothing particularly unusual about application logic like:
$sth->execute('huge select');
while ($sth->fetch('foreign_key')) { ... do some processing which is hard to do in server-side language ...
$sth->execute('insertresulting data');
}
Most drivers do support this kind of interface but they may be reading the
entire result set for "huge select" in advance. However if ti's large enough
then this is only going to really work if you can start a new portal while the
outer portal is actually running on the backend. If the driver tries to cache
the whole result set the programmer will be sad.
Back when I was doing PHP programming and I discovered that PHP's Postgres
driver didn't support this I thought it was an outrageous bug. (It didn't help
that the behaviour was to misbehave randomly rather than throw a meaningful
error.)
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!
