DecimalField max_digits and decimal_places should be optional and more general

[Gavin Wahl]

In Postgres and the SQL standard, it is not necessary to define a precision and scale for NUMERIC/DECIMAL fields. However, Django requires that they be specified.

​https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL

I would like to be able to create an unconstrained NUMERIC field with DecimalField(), but Django gives the error:

(fields.E130) DecimalFields must define a 'decimal_places' attribute.
fields.E132) DecimalFields must define a 'max_digits' attribute.

Also, the precision needs to be allowed to be less than the scale. NUMERIC(1,2) is a valid type that stores numbers of the form -0.00, -0.01,...0.08, 0.09 but Django says:

(fields.E134) 'max_digits' must be greater or equal to 'decimal_places'.

[Tim Graham]

Duplicate of #24920.

[Gavin Wahl]

That's a bug in inspectdb, related to floating-point fields (approximate) in Oracle--I don't understand how it's a duplicate of this. I just want to remove the overly-aggressive validation when using DecimalField (exact).

[Tim Graham]

Introspection fails because Django doesn't have any way to represent numeric with unlimited precision. That representation is what you've requested.

[Gavin Wahl]

That ticket requests an "ImpreciseDecimalField" to represent floating-point (approximate) fields. Django's DecimalField is used to represent exact values.

The Oracle inspectdb bug from the mailing list and ticket look like a floating-point Oracle field getting incorrectly introspected as a DecimalField instead of FloatField (perhaps this was before FloatField existed?). I can contribute a patch to fix the DecimalField validation; I can't fix Oracle introspection.

[Simon Charette]

We should comment on #24920 to denote that it's not only about introspection but I agree with Tim's triage here it's better to focus work in a single ticket and gain introspection support along the way particularly because the other ticket is so old.