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.kla...@aklaver.com
