Skip to content

Comments

Use _effective_decimal_return_scale in Numeric.result_processor#13137

Open
bysiber wants to merge 1 commit intosqlalchemy:mainfrom
bysiber:fix/numeric-decimal-return-scale
Open

Use _effective_decimal_return_scale in Numeric.result_processor#13137
bysiber wants to merge 1 commit intosqlalchemy:mainfrom
bysiber:fix/numeric-decimal-return-scale

Conversation

@bysiber
Copy link

@bysiber bysiber commented Feb 20, 2026

Description

Numeric.result_processor computes the decimal return scale inline, bypassing the decimal_return_scale parameter, while Float.result_processor correctly uses _effective_decimal_return_scale.

Current behavior

# Numeric.result_processor - ignores decimal_return_scale
return processors.to_decimal_processor_factory(
    decimal.Decimal,
    (
        self.scale
        if self.scale is not None
        else self._default_decimal_return_scale
    ),
)

The _effective_decimal_return_scale property (from NumericCommon) checks self.decimal_return_scale first, then falls back to self.scale, then _default_decimal_return_scale. The inline logic in Numeric skips the decimal_return_scale check entirely.

This means Numeric(precision=10, scale=2, decimal_return_scale=5) would use scale 2 instead of 5 when the DBAPI doesn't support native decimals.

Fix

Use self._effective_decimal_return_scale, same as Float.result_processor already does.

# After fix - consistent with Float
return processors.to_decimal_processor_factory(
    decimal.Decimal,
    self._effective_decimal_return_scale,
)

@bysiber
Use _effective_decimal_return_scale in Numeric.result_processor
9d5dbc8 
Numeric.result_processor was computing the return scale inline,
skipping the decimal_return_scale parameter entirely. Float already
uses _effective_decimal_return_scale which checks decimal_return_scale
first. This brings Numeric in line with Float and honors the
decimal_return_scale parameter as documented.
@CaselIT
Copy link
Member

CaselIT commented Feb 20, 2026

Hi,

The PR template asks to open an issue before creating a PR. It's not that difficult an ask.

What's the issue we are trying to solve here?

@bysiber
Copy link
Author

bysiber commented Feb 20, 2026 •
edited
Loading

Apologies for skipping the issue step I'll open one now.

The problem is in Numeric.result_processor: when asdecimal=True and the dialect returns floats, the processor uses self._effective_decimal_return_scale to determine quantization precision. But if the column was defined with Numeric(precision=10) without specifying scale, both self.scale and self.decimal_return_scale are None, so _effective_decimal_return_scale falls back to self._default_decimal_return_scale (10). This means the processor always quantizes to 10 decimal places regardless of the actual data, which may not match the backend's precision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@bysiber @CaselIT