On Mar 28, 2011, at 10:43 AM, Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> On 03/28/2011 11:14 AM, Tom Lane 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? > >> I think we should forbid it for now. If someone comes up with a) a good >> way to make it works and b) a good use case, we can look at it then. I >> expect the PostgreSQL type system to be a good deal more constrained >> than a general in-memory programming language type system. If lack of >> working type recursion were a serious problem surely we'd have seen more >> squawks about this by now. > > The immediate issue in CheckAttributeType() could be fixed by tracking > which types it was processing and not recursing into an already-open > type. Which, not at all coincidentally, is 90% the same code it'll need > to have to throw error. The issue for really "making it work" is how do > we know if there are any other places that need a recursion defense? > I'm pretty sure that find_composite_type_dependencies would, and I don't > know where else there might be a hidden assumption that column > references don't loop. So I think that it's mostly about testing rather > than anything else. If I were fairly confident that I knew where all > the risk spots were, I'd just fix them rather than trying to forbid the > construction.
Perhaps forbid it for now (for safety) but provide the reporter with a patch that would unblock them so they can do further testing? The concept is certainly interesting so it'd be nice to support it if we could. It seems like a good fit for things like storing tree structures. Though, if the type is still hauling around a heap tuple header I think they'll find the performance of this whole thing to be rather lacking... :( -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
