# Postgres composite types
**URL:** https://forum.djangoproject.com/t/postgres-composite-types/32667
**Category:** ORM
**Created:** [July 3, 2024, 3:20pm UTC](https://forum.djangoproject.com/t/postgres-composite-types/32667 "2024-07-03T15:20:37Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@tom](https://forum.djangoproject.com/u/tom)
#### Post date: [July 3, 2024, 3:20pm UTC](https://forum.djangoproject.com/t/postgres-composite-types/32667/1 "2024-07-03T15:20:37Z")
I’d like to open some discussion about adding [composite types for Postgres](https://www.postgresql.org/docs/current/rowtypes.html).
And some [Django implementation ideas](https://schinckel.net/2014/09/24/using-postgres-composite-types-in-django/).
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.
---
### Author:  [@csirmazbendeguz](https://forum.djangoproject.com/u/csirmazbendeguz)
#### Post date: [July 4, 2024, 2:46pm UTC](https://forum.djangoproject.com/t/postgres-composite-types/32667/2 "2024-07-04T14:46:14Z")
@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.
---
### Author:  [@tom](https://forum.djangoproject.com/u/tom)
#### Post date: [July 4, 2024, 3:14pm UTC](https://forum.djangoproject.com/t/postgres-composite-types/32667/3 "2024-07-04T15:14:51Z")
I’m also interested in your work on composite keys here.
Can you tell me how you’d plan to implement these for other databases? I’m not sure they have support for composite types?
---
### Author:  [@csirmazbendeguz](https://forum.djangoproject.com/u/csirmazbendeguz)
#### Post date: [July 4, 2024, 3:27pm UTC](https://forum.djangoproject.com/t/postgres-composite-types/32667/4 "2024-07-04T15:27:08Z")
@tom, you can find my work here: [https://github.com/django/django/pull/18056](https://github.com/django/django/pull/18056)
All reviews are greatly appreciated!
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.
---
### Author:  [@charettes](https://forum.djangoproject.com/u/charettes)
#### Post date: [July 4, 2024, 3:37pm UTC](https://forum.djangoproject.com/t/postgres-composite-types/32667/5 "2024-07-04T15:37:29Z")
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.
---
### Author:  [@csirmazbendeguz](https://forum.djangoproject.com/u/csirmazbendeguz)
#### Post date: [July 4, 2024, 4:33pm UTC](https://forum.djangoproject.com/t/postgres-composite-types/32667/6 "2024-07-04T16:33:33Z")
I suppose it could be interpreted as:
1. `CompositeField` combines 2 fields in Django
2. `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.