Re: Recursive containment of composite types

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Recursive containment of composite types
Дата
Msg-id 17491.1301325263@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Recursive containment of composite types  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: Recursive containment of composite types  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: Problem with streaming replication, backups, and recovery (9.0.x)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Additional options for Sync Replication