Support BIT data type model field for MySQL and PostgreSQL

[Jordan Bae]

Support BIT data type model field for MySQL and PostgreSQL

Currently, Django's model fields do not support the BIT data type which is available in both MySQL and PostgreSQL databases.

Key reasons for adding BIT data type support:

1. Improved Database Inspection
   • When using inspectdb on tables containing BIT columns, Django currently falls back to TextField with a "This field type is a guess" comment
   • Native BitField support would provide accurate model generation for existing databases

2. Database-specific Features
   • MySQL: Support for BIT(M) where M can specify the number of bits
   • PostgreSQL: Support for both BIT(n) and BIT VARYING(n) types

3. Use Cases
   • Efficient storage of boolean flags and bit flags
   • Direct mapping to database-native bit operations
   • Better integration with legacy databases using BIT columns

This enhancement would improve Django's database type coverage and provide more efficient handling of bit-based data.

[Simon Charette]

I'm not convinced that we should add a dedicated field for this given we already have the all purposed BinaryField ​which I don't see mentioned in your report implemented as longblob on ​MySQL and bytea ​on Postgres which should cover most of the usage a BitField would have.

Improved Database Inspection

This argument could stand for pretty much any type that database support and Django doesn't have a field equivalent for.

Efficient storage of boolean flags and bit flags

Apparently bytea ​is more space efficient than bit varying on PostgreSQL so if you've reached a point where the storage of boolean bits and flags is of a concern BinaryField would be a better option on Postgres at least.

Direct mapping to database-native bit operations

These database-native bit operations would need to be implemented as lookups and transforms anyway on the ORM side which is something that could be done with BinaryField as well.

Given that you can likely implement a BitField by subclassing BinaryField, overriding it's db_type ​method to return f"bit({self.max_length})" and that adding a BitField in core ​while there are third-party alternatives would incur a significant maintenance burden I'm going to close this ticket as wontfix.

If you disagree please create a forum discussion to try to form community consensus on the subject ​as documented when proposing new features.

[Jordan Bae]

Thanks for reviewing my suggestion. I totally understood.