Re: Recursive containment of composite types

On Mon, Mar 28, 2011 at 9:54 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Mon, Mar 28, 2011 at 9: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, maybe. In fact, probably.  That's like asking in C if it's sane
> to have a structure to contain a pointer back to itself, which of
> course it is.  That said, if it doesn't work properly, it should
> probably be disabled until it does.

hm, you can work around lack of above at present using two vs one types:
postgres=# create table b ();
postgres=# create table c ();
postgres=# alter table b add c c;
postgres=# alter table c add b b;
postgres=# alter table c add i int;
postgres=# alter table b add j int;
postgres=# select row(row(null, 1), 1)::b;
row
------------
("(,1)",1)

This isn't great but might cover some of the cases where you need such
a thing (and I tested this on 8.1).

merlin