Re: Recursive containment of composite types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Recursive containment of composite types
Date
Msg-id 17491.1301325263@sss.pgh.pa.us
Whole thread Raw
In response to Re: Recursive containment of composite types  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Recursive containment of composite types
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: hubert depesz lubaczewski
Date:
Subject: Re: Problem with streaming replication, backups, and recovery (9.0.x)
Next
From: Robert Haas
Date:
Subject: Re: Additional options for Sync Replication