Skip site navigation (1) Skip section navigation (2)

Re: Recursive containment of composite types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Recursive containment of composite types
Date: 2011-03-28 15:43:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)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

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Jan WieckDate: 2011-03-28 16:17:54
Subject: Re: Lock problem with autovacuum truncating heap
Previous:From: Greg StarkDate: 2011-03-28 15:40:10
Subject: Re: Additional options for Sync Replication

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group