From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
---|---|
To: | Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk> |
Cc: | "pgsql-general (at) postgresql (dot) org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Incomprehensible behaviour of a foreign key. |
Date: | 2003-07-20 14:10:09 |
Message-ID: | Pine.LNX.4.21.0307201458030.16690-100000@ponder.fairway2k.co.uk |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, 20 Jul 2003, Paul Thomas wrote:
>
> On 20/07/2003 14:15 Nigel J. Andrews wrote:
> >
> > As usual I forgot to include the version number. It's 7.3.3
> > >
> > > I'd really appreciate an explanation, since this test is based on
> > queries
> > > extracted from the db log, is only one specific example of this sort of
> > > operation from many in the driving program and most significantly it
> > seems I
> > > can't even write sql statments hardcoding these values as the test
> > script shows
> > > they still get the ref. int. error.
>
> A bit more detail about the tables might be helpful, constraints, triggers
> etc... How about doing a select of site_membership immediately before the
> delete. What does that show? Have you got a trigger somewhere that would
> insert a record into site_membership? This could cause the RI failure but,
> without the transaction being committed, the inserted record could be
> discarded and the table would still appear empty after the error. I'm very
> much clutching at straws here and am probably way off but without more
> details, wild guesses are the best I can do.
I understand, and that's all I'm hoping for at this stage.
No, there's no triggers on any of these tables. In the test script
site_membership is still empty immediately before the delete.
Nigel Andrews
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-07-20 14:31:08 | Re: Incomprehensible behaviour of a foreign key. |
Previous Message | Paul Thomas | 2003-07-20 13:55:21 | Re: Incomprehensible behaviour of a foreign key. |