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. If someone wants to do the work to make it work
in some future release, we can consider it, but I think there are
other aspects of the type system that are more worthy of our attention
than this one is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company