On Mon, Mar 28, 2011 at 10: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, essentially what you'd be doing is making a linked list data
type. t contains an id, and perhaps also another t. You can travel
down through arbitrarily many objects of type t, each of which has an
id value, and eventually you'll hit one where t.childs is NULL. So
it's semantically sensible, I believe, but it seems perfectly sensible
to just prohibit it.
This makes me think of HL7 datatypes R1
http://www.hl7.org/v3ballot2011jan/html/welcome/environment/index.html
and
http://www.hl7.org/v3ballot2011jan/html/infrastructure/datatypes/datatypes.html
where a Concept Descriptor type has as attribute a set of concept
descriptor types.
Regarding the bug: if recursion causes errors, cycles could be dangerous
as well.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
