| From: | Daniel Fortunov <postgresql(at)danielfortunov(dot)com> |
|---|---|
| To: | Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> |
| Cc: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, psycopg(at)postgresql(dot)org |
| Subject: | Re: Latest developments in psycopg3 |
| Date: | 2021-02-08 22:38:10 |
| Message-ID: | CAH1rg6b41jgi2A7qOaUGx1KwkuzD3hNMFWwfcQPKb1Oy5FGVRQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | psycopg |
>
> > 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()
>
> Inheriting from dict is strange because we only need read access. So
> rather collections.abc.Mapping, I think.
>
One advantage of using a real dict is that it leaves the door open for the
caller to mutate the results as they consume them. A little impure, I know,
but one practical example I can think of would be where you want to augment
your results with additional data (coming from a different source, outside
the database).
RealDictCursor gives you the flexibility to do this, whereas
collections.abc.Mapping would force you to construct a new dict instance
for every row in order to get the same result.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniele Varrazzo | 2021-02-10 12:43:39 | Re: about client-side cursors |
| Previous Message | Rory Campbell-Lange | 2021-02-08 16:50:14 | Re: Latest developments in psycopg3 |