Re: Recursive containment of composite types

On 03/28/2011 11:14 AM, Tom Lane wrote:
> Merlin Moncure<mmoncure@gmail.com>  writes:
>>> On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane<tgl@sss.pgh.pa.us>  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 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;
> Well, that'd have to be disallowed too under what I have in mind.
> Indirect recursion is no safer than direct.  If you try
>
> alter table b add k serial;
>
> at this point, you'll get the same crash or failure as for the direct
> recursion case.
>
>             

I think we should forbid it for now. If someone comes up with a) a good 
way to make it works and b) a good use case, we can look at it then. I 
expect the PostgreSQL type system to be a good deal more constrained 
than a general in-memory programming language type system. If lack of 
working type recursion were a serious problem surely we'd have seen more 
squawks about this by now.

cheers

andrew