Am 26.03.2018 um 22:01 schrieb Justin Pryzby:
> I have one patch ready for evaluation.
>
> 1: implement fake/pseudo cursors in pg (same as what's in pgdb);
> I proposed not to support any "move()" function in pg, since
> there's no "fetch" (besides getItem which is newly introduced
> at your suggestion). This patch is solid.
>
> I also have additional patches which are "in progress" and less
> solid. I'll prepare after you after your evaluation of (1).
Thanks again for pushing this forward and sorry for taking so long to
reply. Let's concentrate on patch 1 first, which is essentially about
adding the sequence and iterator protocols to the classic pg query. We
should really get this into version 5.1 as it makes a lot of sense
syntactically, even though memory-wise we don't get much benefits since
it cannot prevent that the result list is always completely read into
memory (due to the way pqlib works). We can talk about server side
cursors later in version 5.2 or 6.
Some remarks:
* This doesn't work with Python 3 yet, but it's probably easy to fix.
For instance, Py_TPFLAGS_HAVE_ITER does not exist in Python 3. We could
provide it via py3c.h (would be simply 0 in Python 3).
* I don't think max_row and num_fields should be stored in the
queryObject, since they can easily be accessed as PQntuples(obj->result)
and PQnfields(obj->result), which is actually only a cheap lookup.
Better to have a single source of truth only. Storing col_types might be
reasonable, but:
* testSetByteaEscaped and testSetDecimalPoint fail because the col_types
depend on global settings. Tf you change these settings after executing
the query and before getting the result, the changes in the settings are
not reflected. Not sure if we should just adapt the test or not store
col_types and get them dynamically (see point above).
* TestDictIteratorQueries.testIterate fails, but this is easy to fix
(the test is the problem, not the implementation)
* Needs some tests for raising IndexErrors (this works already)
* We should also implement sq._contains (__contains__) and __reversed__
to make the sequence protocol more complete.
* We might want to deprecate ntuples() since it's the same as len() now.
* To be consistent with the old method names (dictresult and
namedresult), dictIter and namedIter should become dictiter and
namediter. If we really want nicer names, then it should be named_iter
and dict_iter according to PEP8, but then we should also provide
get_result, dict_result and named_result, as aliases and deprecated the
old names. Not sure if we want that.
* Would it make sense to make the result row type configurable by
providing get/set_result_type() methods on the module, connection and
query level? We could then get rid of the 6 different accessor methods
for the result result list/iter and simply call list() or iter() on the
query (or just iterate over it, or access items directly). Not sure
whether this is a silly or clever idea, what do you think?
I'll clean up and implement your patch for 5.1, but want to clarify the
above points first.
-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo.cgi/pygresql
