"Stephen R. van den Berg" <[EMAIL PROTECTED]> 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('insert resulting 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers