Database type NUMERIC with no parameters is not supported

[Shai Berger]

Django's DecimalField requires both max_digits and decimal_places. Database backends allow them to be dropped, to specify an "unlimited precision" field.

This leads to bugs in inspectdb: On Oracle, a column defined as NUMERIC is inspected as having 0 digits and negative precision; on Postgresql, it is inspected as having 65535 (a C short -1?) digits and decimal places, when the ​documentation says you can only explicitly define up to 1000 decimal places (and even the implicitly defined precision is only 16383).

Discussion in the context of Oracle (from 2012):
​https://groups.google.com/d/topic/django-developers/qSAfzPyqKqw/discussion

(This could be solved more easily by adding a new field type than by modifying the behavior of the existing DecimalField; however, I'm having a hard time suggesting a name for such a field type, which may be an indication that it is a bad interface. Besides that decision, this probably applies as an easy picking).

[Tim Graham]

Maybe you could raise the idea on the DevelopersMailingList. I think I'd prefer if we didn't need to add a new field, but if so, I'll propose the name ImpreciseDecimalField. Seems like a name like that might scare people away from using it though.

[Maciej Gol]

Any update on this or a suggested way of resolving: either new field or a fix to DecimalField?

[Tim Graham]

If you want to propose a solution, please write to the DevelopersMailingList to get feedback about how to proceed.

[Tim Graham]

On the ​django-developers thread, Aymeric proposed trying to adapt DecimalField rather than introduce a new field, and Claude gave that idea a +1.

#36673 is a duplicate that requests making DecimalField's max_digits and decimal_places optional.

[Mariusz Felisiak]

​PR

[GitHub <noreply@…>]

In 1ce6e78:

Fixed #24920 -- Added support for DecimalField with no precision.

Thanks Lily for the review.

[GitHub <noreply@…>]

In 1c34b871:

Refs #24920 -- Made DecimalField system checks database dependent.

Thanks Tim Graham for the suggestion.

[Sarah Boyce <42296566+sarahboyce@…>]

In a3e6e7d:

Fixed #37275, Refs #24920 -- Fixed SQLite DecimalField conversion without precision.

Thank you Matt Cooper for the report and Mariusz Felisiak for the review.

[Sarah Boyce <42296566+sarahboyce@…>]

In ad6bc546:

[6.1.x] Fixed #37275, Refs #24920 -- Fixed SQLite DecimalField conversion without precision.

Thank you Matt Cooper for the report and Mariusz Felisiak for the review.

Backport of a3e6e7d3aa6e2aa793ba1d122a76cb007727197c from main.