Re: Recursive containment of composite types

On 03/28/2011 11:14 AM, Tom Lane wrote:
> Merlin Moncure<mmoncure(at)gmail(dot)com> writes:
>>> On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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