On 15 Nov 2013, at 8:04 pm, Chris Travers <chris.travers@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
theway 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
thanthe latter.
>
> Where composite types really work well is where you want to add functions which take the type as input. In essence
youcan develop some very sophisticated models with them, but you probably would not use them for storage unless you
haveother 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
likea column definition template. This also automatically creates a type that can be used in functions which sounds
likewhat I’m after. There are also scenarios where “product” is a combination of “level" and “id” (where “level” can be
thingslike brand/category/sku) and I’d like to use the same calculations regardless of where it sits in the hierarchy.
Cheers,
Tony