fix: NUMERIC vs BIGNUMERIC column type selection based on precision and scale

[claytonjroberts]

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes googleapis/google-cloud-python#15765 🦕

[Linchin]

As we discussed in googleapis/google-cloud-python#15765, I think we need to verify the precision and scale in two situations:

1. the default NUMERIC/BIGNUMERIC. Example: sa.Column("id", NUMERIC())
2. the parameterized NUMERIC/BIGNUMERIC. Example: sa.Column("id", NUMERIC(37, 0))

I think your code change only covers the second. Could you add logic to distinguish between the two and add back the verification for the first?

Also, please add unit tests and system test for these specific cases. Thank you!

[claytonjroberts]

@Linchin

My code should cover both your cases. If precision or scale is None, it is assumed 0 in the calculation.

What case am I missing?

from dataclasses import dataclass


@dataclass
class FakeType:
    precision: int | None
    scale: int | None


def numeric_or_bignumeric(type_) -> str:
    return (
        "NUMERIC"
        if (0 <= (type_.precision or 0) - (type_.scale or 0) <= 29)
        else "BIGNUMERIC"
    )


if __name__ == "__main__":
    assert numeric_or_bignumeric(FakeType(29, 0)) == "NUMERIC"
    assert numeric_or_bignumeric(FakeType(29, 1)) == "NUMERIC"
    assert numeric_or_bignumeric(FakeType(None, None)) == "NUMERIC"
    assert numeric_or_bignumeric(FakeType(30, 0)) == "BIGNUMERIC"
    assert numeric_or_bignumeric(FakeType(30, 1)) == "NUMERIC"
    assert numeric_or_bignumeric(FakeType(30, None)) == "BIGNUMERIC"
    assert numeric_or_bignumeric(FakeType(None, 5)) == "BIGNUMERIC"
    print("All tests passed!")

[chalmerlowe]

Migration Notice: This library is moving to the google-cloud-python monorepo soon.

We closed this PR due to inactivity to ensure a clean migration. Please re-open this work in the new monorepo once the migration is complete!