From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Chris Mair <chrisnospam(at)1006(dot)org>, MAR - Secretariado Geral <secretariadogeral(at)acra(dot)pt>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Foreign keys |
Date: | 2006-09-10 15:09:31 |
Message-ID: | 6967.1157900971@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> I think if we were going to do this that all the constraint violations for
> unique, not null, check and foreign keys should be handled similarly, so
> we'd probably want something more general than just a way for the ri
> triggers to do this. I don't have a good idea of the right solution for
> that though.
It seems pretty unwieldy to me: it's not hard to imagine a long INSERT
throwing millions of separate foreign-key errors before it's done, for
instance. And then there's the cascading-errors problem, ie, bogus
reports that happen because some prior step failed ... not least being
your client crashing and failing to tell you anything about what
happened because it ran out of memory for the error list.
My advice is to rethink the client code that wants such a behavior.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Kronuz | 2006-09-10 15:21:16 | Re: ISBN/ISSN/ISMN/EAN13 module |
Previous Message | Stephan Szabo | 2006-09-10 14:19:36 | Re: Foreign keys |