Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Decimal in money range still string-binds on the executemany path

Ouverte
  • Quelque chose ne va pas ?
#745 1 commentaire 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@bewithgaurav y travaille déjà.

Depuis le 21/9/2026.

  • #752 par @vyrnsynx — ouverte
  • #770 par @IMGillusion — fermée sans fusion

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
python, sql
Domaine
databases

Piste de recherche

Commencez par suivre le chemin de liaison des paramètres de executemany et comparez-le aux correctifs de execute() de #740. Reproduisez le lot de Decimal avec numeric(5,2), puis prenez en compte la précision et l’échelle de l’ensemble du lot tout en préservant le comportement de liaison de chaînes de GH-503 et le dimensionnement des signes mixtes de GH-557 ; le travail est terminé lorsque le lot est lié correctement en tant que SQL_NUMERIC sans ces régressions.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

area: data-types bug triage done under development
Describe the bug

#740 fixed money-range Decimal binding on both execute() routes (the native C++ path and the Python legacy path used when setinputsizes() covers fewer positions than parameters). executemany() is the one remaining path that still carries the money-range VARCHAR shortcut, so a money-range Decimal compared through executemany can still overflow:

cur.executemany("UPDATE t SET x = 1 WHERE v = ?", [(Decimal("12345.6789"),)])
# against v numeric(5,2): Arithmetic overflow error converting varchar to data type numeric

This is a non-shape in practice (executemany runs the statement per row and discards results, so nobody runs a comparison-SELECT through it), and it is not reachable from Django, which is why it is lower priority than #740.

Why it was scoped out of #740

executemany declares one parameter type for the whole batch and lets the server coerce each row's formatted string (GH-503). Switching money-range Decimals to SQL_NUMERIC there needs a single NUMERIC(precision, scale) that fits every row in the batch, which the code does not compute today — it tracks max string length, not max precision and scale. A naive switch regresses a mixed-sign batch (the GH-557 shape) with a string-truncation error.

Suggested fix

Add batch-wide precision/scale derivation in executemany so it can bind money-range Decimals as SQL_NUMERIC (like both execute() paths) without breaking the GH-503 batch string binding or the GH-557 mixed-sign column sizing.

Further technical details

mssql-python version: reproduces on the main branch alongside #740.
SQL Server version: SQL Server 2022
Operating system: driver-side, OS-independent

Langage dominant
Python
Étoiles
478
Forks
62
Merge moyen
3 j 1 h
PR mergées (30 j)
27

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/mssql-python

Toutes les issues de microsoft/mssql-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.