Type constraints in 65 lines of SQL

Nice article. I&#x27;ve used composite types with success for similar problems. Some tips:<p>- Composite types are useful for data validation. Money types and unit-based types are good for composite types.<p>- Avoid over-using composite types. Most of the time, regular columns are better. Not many tools interact well with composite types, like reporting tools or database libraries.<p>- Like the article notes, avoid using composite types for data types that may change.<p>- A JSONB domain type is a good alternative for data types that change often. Note that if you put the validation into a helper function, Postgres will not revalidate the domain if the function definition changes.<p>- Using composite types is mildly annoying since you must wrap the composite column in parenthesis to access the field.<p><pre><code> -- Bad SELECT package_semver.major FROM package_version; -- Errors with `missing FROM-clause entry for table &quot;package_semver&quot;` -- Good SELECT (package_semver).major FROM package_version; </code></pre> - When defining a domain type, separate checks into named constraints with ALTER DOMAIN. The Postgres error message for check validation failures is lackluster and provides little beyond &quot;it failed.&quot;<p><pre><code> CREATE DOMAIN item_delta_node AS jsonb NOT NULL; ALTER DOMAIN item_delta_node ADD CONSTRAINT item_delta_node_is_object CHECK (coalesce(jsonb_typeof(value), &#x27;&#x27;) = &#x27;object&#x27;); ALTER DOMAIN item_delta_node ADD CONSTRAINT item_delta_node_item_delta_id_null_or_num CHECK (coalesce(jsonb_typeof(value[&#x27;item_delta_id&#x27;]), &#x27;number&#x27;) IN (&#x27;null&#x27;, &#x27;number&#x27;));</code></pre>

Any idea of how to implement tagged unions in Postgres. For example, Tree a = Leaf a | Branch (Tree a, Tree a)<p>This is one data type feature which would be great to have. I know you can create separate tables for each option in the type and use an id, but is a direct type implementation possible?<p>Dont need polymorphism(say a = String). Even a non recursive tagged union would be helpful.

I often wonder about this kind of solution compared with a more traditional solution of using a table of columns and constraints. There seems like there should be an obvious heuristic of when to use one or the other but it eludes me.

hi, author here happy to answer any questions<p>another approach that works great is to use `create type`[1] with an `input_function` and `output_function` to build on top of an existing scalar type. For example, using that method would allow semver to be persisted as a string natively. The only downside to that is you have to be superuser.<p>[1] <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;sql-createtype.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;sql-createtype.html</a>

The benefits of having a better type and form constraint is obvious. But you should remember that offloading computation to the DB, especially one that isn&#x27;t fully distributed like Postgres. Might bite you later down the line.

I once heard that data validation should be implemented in back end server but not datsbase because the latter is more difficult to scale horizontally and usually the bottleneck of transaction performance.<p>Is that true?