Re: Recursive containment of composite types

> On Mon, Mar 28, 2011 at 10:47 AM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>> Bug #5950 proposes the following test case:
>>
>> create table t ();
>> alter table t add childs t;
>> alter table t add id serial not null primary key;
>>
>> Most of the back branches dump core because CheckAttributeType() goes
>> into infinite recursion.  That doesn't happen in HEAD, but so far as I
>> can see that's just because of some chance rearrangement of the order of
>> operations in ALTER TABLE.  I wouldn't be at all surprised if there are
>> related cases where HEAD fails too.
>>
>> I think the most straightforward and reliable fix for this would be to
>> forbid recursive containment of a rowtype in itself --- ie, the first
>> ALTER should have been rejected.  Can anyone think of a situation where
>> it would be sane to allow such a thing?
> Well, essentially what you'd be doing is making a linked list data
> type.  t contains an id, and perhaps also another t.  You can travel
> down through arbitrarily many objects of type t, each of which has an
> id value, and eventually you'll hit one where t.childs is NULL.  So
> it's semantically sensible, I believe, but it seems perfectly sensible
> to just prohibit it.
This makes me think of HL7 datatypes R1 
http://www.hl7.org/v3ballot2011jan/html/welcome/environment/index.html 
and 
http://www.hl7.org/v3ballot2011jan/html/infrastructure/datatypes/datatypes.html 
where a Concept Descriptor type has as attribute a set of concept 
descriptor types.

Regarding the bug: if recursion causes errors, cycles could be dangerous 
as well.

-- 
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data