MagicStack / MagicStack/asyncpg
Late/optional decoding?
Open
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.
- Is there a way to delay decoding results until actually looking at data and interpreting it would become necessary?
- 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?
- Would that potentially avoid the need to issue type introspection queries?
- If not as of today, would this become easier once @vmarkovtsev's
asyncpg-rktfork gets merged back upstream? - 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
decimaltype? I personally find that python'sdatetimeis terrible and Postgres timestamps can fall outside of the range that can be represented viadatetime. Should such a decimal codec come withasyncpg, 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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