I wanted to pick this up and finally finish it.. Some opened question in my mind:
- should we implement real serverside cursors instead? Or is that off the table for "classic" interface for some reason? - Or should we implement enough of serverside cursors to be sure of what interfaces to expose (it's easy enough, but want to avoid have two different interfaces). - What would that look like if it were implemented ? I imagine we wouldn't prefix every SELECT with CREATE CURSOR AS, but rather maybe accept a cursorname='...' argument to query() ? On Fri, Jul 14, 2017 at 07:28:14PM +0200, Christoph Zwerschke wrote: > Am 09.07.2017 um 23:19 schrieb Justin Pryzby: > >Here's another revision; I haven't implemented named result iterators, and > >still couldn't get len() to work. Thanks for working > >on this. This seems to go into the right direction. > Looks like it is not sufficient to just add a __len__() function in the C > module, but you need to add a struct queryTypeSequenceMethods of type > PySequenceMethods that contains the len() method, and point to this struct > in the tp_as_sequence member of the queryType PyTypeObject. > > See here: > https://docs.python.org/3/c-api/typeobj.html#c.PySequenceMethods > > Besides sq_length, you should probably also implement sq_item. The other > members of PySequenceMethods can be NULL. > > >One possibility is if col_types was stored in the queryObject struct, > >and either invalidated by query() and populated lazily by first call > >to result function or (probably) just populated by query() for use by > >various result functions. Is that reasoanble? > Yes, it would make sense to cache the result of get_col_types(). You must > not forget to free the memory in queryDealloc() then. I did this now, I'll send a patch shortly. Note, all the *result() and Iter() interfaces are re-setting current_row=0. I think that gives the needed behavior: calling getresult() multiple times returns the same thing (changing this could break anything depending on prior behavior), rather than a parital result set if previously iterated over a full or partial result. Also allows iterating over a result multiple times without having to call Move(). That's slightly desriable too as it just DTRT. I don't think we should support partial result sets from getresult() et al. But, should it be possible to get a partial result by iteration? I don't know what that would look like; I guess supporting getitem() is sufficient for that case. Justin _______________________________________________ PyGreSQL mailing list [email protected] https://mail.vex.net/mailman/listinfo.cgi/pygresql
