On 15 Nov 2013, at 8:04 pm, Chris Travers <chris.travers@xxxxxxxxx> wrote: > > In general, if you don't know you need composite types, you don't want them. You have basically three options and the way you are doing it is the most typical solution to the problem The current way is much easier since I discovered the “JOIN ... USING(..)” syntax and I’m tempted to try natural joins. > Having experience with table inheritance and composite types in tuples, I will say the former has fewer sharp corners than the latter. > > Where composite types really work well is where you want to add functions which take the type as input. In essence you can develop some very sophisticated models with them, but you probably would not use them for storage unless you have other considerations in mind. Thanks for that, I’ve done some reading on inheritance and it looks like I can create an empty parent table that acts like a column definition template. This also automatically creates a type that can be used in functions which sounds like what I’m after. There are also scenarios where “product” is a combination of “level" and “id” (where “level” can be things like brand/category/sku) and I’d like to use the same calculations regardless of where it sits in the hierarchy. Cheers, Tony -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
