Re: Recursive containment of composite types

> On Mon, Mar 28, 2011 at 10:47 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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