There is a bit of awkwardness here in that the user will have to write their own migration to create the type. This is a similar problem to what we’d face trying to implement enums, and we already have some precedent here in CreateExtension and CreateCollation.
Composite types can be quite useful when you feel a new table is overkill, but an ArrayField with a small number of elements of composite fields are quite useful, rather than defining a few sets of several fields that can be quite a bit of duplication. I think they could also be useful for specifying bits of data that only make sense together (e.g. you need either both or none), though I’ve never used it in this way, and a constraint works almost as well here.
That said, while it has a few use-cases that I occasionally have, I am not sure it’s widely used enough to add to core, so I thought i’d gather some more opinions.
@Lily-Foote , @charettes , @carltongibson ^^
This is what I meant by composite primary keys != composite fields. To me, generic composite fields only make sense if it’s implemented like suggested above.
As for the composite types, it depends on the application of course. We could’ve used it in an app where we had a lot of “money” fields (e.g. 100 USD). I guess it’s slightly more expressive on the db side than having 2 columns.
IMO just like Postgres table inheritance has little to do with Django model inheritance Postgres composite types are a different feature than what CompositeField is meant to solve in your work @csirmazbendeguz.
The work led by @Lily-Foote and yourself on CompositeField has more to do with exposing a way to have a Django field composed of multiple table columns while Postgres composite types are way to declare user defined column types composed of other column types.
In my opinion @tom what is called CompositeField in the article you linked should be named CompositeTypeField and represents a different feature that only Postgres appear to support.
CompositeTypeField combines 2 fields in the database
One can argue if CompositeTypeField is useful for combining database fields, CompositeField is also useful for combining Django fields. I initially failed to see the usefulness CompositeField, but I suppose if we accept that combining fields is a useful abstraction, it makes sense.