On 15 Nov 2013, at 8:04 pm, Chris Travers <chris.trav...@gmail.com> 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
