On Thu, Mar 18, 2010 at 1:21 PM, Yeb Havinga <yebhavi...@gmail.com> wrote: > Tom Lane wrote: >> >> Yeb Havinga <yebhavi...@gmail.com> writes: >> >>> >>> What if the default operation of e.g. php using libpq would be as >>> follows: set some default fetchsize (e.g. 1000 rows), then just issue >>> getrow. In the php pg handling, a function like getnextrow would wait for >>> the first pgresult with 1000 rows. Then if the pgresult is depleted or >>> almost depleted, request the next pgresult automatically. I see a lot of >>> benefits like less memory requirements in libpq, less new users with why is >>> my query so slow before the first row, and almost no concerns. >>> >> >> You are blithely ignoring the reasons why libpq doesn't do this. The >> main one being that it's impossible to cope sanely with queries that >> fail partway through execution. > > I'm sorry I forgot to add a reference to your post of > http://archives.postgresql.org/pgsql-general/2010-02/msg00956.php which is > the only reference to queries failing partway that I know of. But blithely > is not a good description of me ignoring it. I though about how queries > could fail, but can't think of anything else than e.g. memory exhaustion, > and that is just one of the things that is improved this way. Maybe a user > defined type with an error on certain data values, but then the same arguing > could be: why support UDT? And if a query fails during execution, does that > mean that the rows returned until that point are wrong? >> >> The described implementation would not >> cope tremendously well with nonsequential access to the resultset, either. >> > > That's why I'm not proposing to replace the current way pgresults are made > complete, but just an extra option to enable developers using the libpq > libary making the choice themselves.
This seems pretty reasonable to me, especially considering that JDBC is apparently already doing it. I suppose there will always be projects that want to reimplement the backend protocol so that they can be "pure" some-language, but chipping away at the list of other reasons why someone might not want to use libpq still seems like a good idea. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
