On Mon, Mar 28, 2011 at 9:54 AM, Merlin Moncure <mmonc...@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane <t...@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.
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;
postgres=# alter table c add i int;
postgres=# alter table b add j int;
postgres=# select row(row(null, 1), 1)::b;
row
------------
("(,1)",1)
This isn't great but might cover some of the cases where you need such
a thing (and I tested this on 8.1).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
