MagicStack / MagicStack/asyncpg

Late/optional decoding?

Open
#1,112 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
8.1k
Forks
468
PR merge metrics
No merged PRs in 30d

Description

I have a few interrelated questions. Some might even be blasphemous for lack of in-depth knowledge of the wire protocol on my part.

1. Is there a way to delay decoding results until actually looking at data and interpreting it would become necessary?
2. Similarly, would it be possible to take undecoded "records" (not in the strict field-to-value map sense of asyncpg records) and pass them as-is to an upsert without having to re-encode them, so long as the bound arguments correspond to those returned by the previous query?
3. Would that potentially avoid the need to issue type introspection queries?
4. If not as of today, would this become easier once @vmarkovtsev's `asyncpg-rkt` fork gets merged back upstream?
5. Otherwise, at the very least, would it be possible to decode timestamps to something closer to their internal postgres representation - for example mapping them to the Python's `decimal` type? I personally find that python's `datetime` is terrible and Postgres timestamps can fall outside of the range that can be represented via `datetime`. Should such a decimal codec come with `asyncpg`, or should everyone write their own if and only if they think they need it?

Thank you & happy new year!

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by tracing asyncpg's decoding, type-introspection, record forwarding, and timestamp codec paths, then determine whether these requests can be scoped independently; done would require a maintainer-approved design or a clearly bounded implementation plan.

Written by the indexing model from the issue text.

Assessment

Tech stack
postgresql, python
Domain
backend, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.