Re: Recursive containment of composite types
От | Merlin Moncure |
---|---|
Тема | Re: Recursive containment of composite types |
Дата | |
Msg-id | AANLkTi=J1abRR+uuSxtJ-v2X6s7u49uHJ8Lsvp1z71w_@mail.gmail.com обсуждение исходный текст |
Ответ на | Recursive containment of composite types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Recursive containment of composite types
Re: Recursive containment of composite types |
Список | pgsql-hackers |
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bug #5950 proposes the following test case: > > create table t (); > alter table t add childs t; > alter table t add id serial not null primary key; > > Most of the back branches dump core because CheckAttributeType() goes > into infinite recursion. That doesn't happen in HEAD, but so far as I > can see that's just because of some chance rearrangement of the order of > operations in ALTER TABLE. I wouldn't be at all surprised if there are > related cases where HEAD fails too. > > 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. merlin
В списке pgsql-hackers по дате отправления: