From 2399b71203168f9905236380379ed3cadd6d3f4c Mon Sep 17 00:00:00 2001 From: Laurenz Albe Date: Thu, 14 Dec 2023 06:41:18 +0100 Subject: [PATCH] Document the dangers of composite type columns Table columns of a composite type are usually not a good idea, as they violate the first normal form. Moreover, if you create an index on a composite type and later use ALTER TYPE to modify the type, the index can get corrupted. Author: Laurenz Albe Discussion: https://postgr.es/m/18244-8a7897de2acd5a08%40postgresql.org --- doc/src/sgml/rowtypes.sgml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/doc/src/sgml/rowtypes.sgml b/doc/src/sgml/rowtypes.sgml index 4d86f97c03..6a3beaf7d0 100644 --- a/doc/src/sgml/rowtypes.sgml +++ b/doc/src/sgml/rowtypes.sgml @@ -67,6 +67,16 @@ SELECT price_extension(item, 10) FROM on_hand; + + + While you can use composite types in column definitions, there is usually no + benefit in doing so. Also, if you create indexes on composite type columns, + beware of using ALTER TYPE to modify the type definition: + doing that could break the requirement that index expressions must be + immutable and might render the index corrupted. + + + Whenever you create a table, a composite type is also automatically created, with the same name as the table, to represent the table's -- 2.43.0