On 03/28/2011 11:14 AM, Tom Lane wrote:
Merlin Moncure<mmonc...@gmail.com> writes:
On Mon, Mar 28, 2011 at 9:47 AM, Tom Lane<t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
