Re: [HACKERS] Recursive containment of composite types

2011-04-05 Thread Jim Nasby
On Mar 28, 2011, at 10:43 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 03/28/2011 11:14 AM, Tom Lane wrote: 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 rejec

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Peter Eisentraut
On mån, 2011-03-28 at 09:54 -0500, Merlin Moncure wrote: > 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. But this is not a pointer, it's containment. SQL has pointers, too (reference types)

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Tom Lane
Andrew Dunstan writes: > On 03/28/2011 11:14 AM, Tom Lane wrote: >>> 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 w

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Andrew Dunstan
On 03/28/2011 11:14 AM, Tom Lane wrote: Merlin Moncure writes: On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane wrote: 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

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Tom Lane
Merlin Moncure writes: >> On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane wrote: >>> 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 whe

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Yeb Havinga
On Mon, Mar 28, 2011 at 10:47 AM, Tom Lane 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 do

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Merlin Moncure
On Mon, Mar 28, 2011 at 9:54 AM, Merlin Moncure wrote: > On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane 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 dum

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Merlin Moncure
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane 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 recursio

Re: [HACKERS] Recursive containment of composite types

2011-03-28 Thread Robert Haas
On Mon, Mar 28, 2011 at 10:47 AM, Tom Lane 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 recursi