Recursive containment of composite types - Mailing list pgsql-hackers

From Tom Lane
Subject Recursive containment of composite types
Date
Msg-id 17149.1301323667@sss.pgh.pa.us
Whole thread Raw
Responses Re: Recursive containment of composite types
Re: Recursive containment of composite types
List pgsql-hackers
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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Euler Taveira de Oliveira
Date:
Subject: Re: Comments on system tables and columns
Next
From: Merlin Moncure
Date:
Subject: Re: Set hint bits upon eviction from BufMgr