From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:35:44 |
Message-ID: | 4D90AAD0.2030303@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/28/2011 11:14 AM, Tom Lane wrote:
> Merlin Moncure<mmoncure(at)gmail(dot)com> writes:
>>> On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> 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?
>>> 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;
> Well, that'd have to be disallowed too under what I have in mind.
> Indirect recursion is no safer than direct. If you try
>
> alter table b add k serial;
>
> at this point, you'll get the same crash or failure as for the direct
> recursion case.
>
>
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2011-03-28 15:40:10 | Re: Additional options for Sync Replication |
Previous Message | Tom Lane | 2011-03-28 15:27:05 | Re: Proposal: q-gram GIN and GiST indexes |