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
|
Список | 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 по дате отправления: