Re: Latest developments in psycopg3

On 2/8/21 4:16 AM, Daniele Varrazzo wrote:
> Hello Denis,
> 

> In short: yes, I would like to provide alternative record factories.
> We can review if the best way is to create cursor subclasses
> out-of-the-box or mixins. In psycopg2 there are:
> 
> - DictCursor (returns a hybrid object between a sequence and a dictionary)
> - RealDictCursor (returns a straight subclass of a dictionary, so it's
> not a legit dbapi cursor as it doesn't expose a sequence)
> - NamedTupleCursor (what it says on the tin).
> 
> Personally I use the NamedTupeCursor most often, as I prefer the dot
> notation to access attribute. Named tuples also have a _dict() method
> when a dict is needed. If psycopg3 was only my pet project, I would
> personally have NamedTuples as the default and only thing supported...
> But that's hardly the case.
> 
> 1) We can provide a feature to select the type of cursor that is not
> much dissimilar from psycopg2
> 2) Do we need DictCursor/RealDictCursor? ISTM that one of the two
> would be sufficient? Possibly an object inheriting from a Python dict
> instead of emulating it so that e.g. json.dumps()

RealDictCursor is what I use primarily as it plays well with json.*. I 
have used NamedTupleCursor for those things that play better with dot 
notation. I very rarely use DictCursor anymore as it's dual nature 
seemed to get in the way more then it helped.

> 3) Or, conversely, we could have a Row object providing both attribute
> and getattr access, both as index and name:
> 
>     row.myattr
>     row["myattr"]
>     row[1]
> 
> 4) There are reports of the *DictCursor being slow: the objects in
> psycopg2 have hardly been profiled. I would look well at the
> performance of the objects created.
> 


> -- Daniele
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com