From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marc Evans <Marc(at)SoftwareHackery(dot)Com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Odd behavior observed |
Date: | 2006-09-19 17:38:07 |
Message-ID: | 9014.1158687487@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Marc Evans <Marc(at)SoftwareHackery(dot)Com> writes:
> On Tue, 19 Sep 2006, Tom Lane wrote:
>> Hmph. You got any ON INSERT triggers or rules on that table? I can't
>> think of anything else that would interfere with data getting stored.
> No INSERT triggers. I do have a BEFORE DELETE trigger, and a pile of
> FOREIGN KEY items (which work kinda like an INSERT trigger).
Hard to see how those could be related --- but it's even harder to
credit that the INSERT would get past the parser with an explicit
reference to the new column and then not store it. I think maybe
something is applying an UPDATE to the row and losing the new value
at that point. Are any of the FKs non-default actions (ON ... SET NULL
or some such that would try to alter data instead of just erroring)?
Also, can you check the cmin field of that row and see if it's greater
than zero?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Evans | 2006-09-19 17:56:47 | Re: Odd behavior observed |
Previous Message | Brandon Aiken | 2006-09-19 17:31:02 | Re: vista |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-19 17:39:58 | Ready for 8.2beta1? |
Previous Message | Brandon Aiken | 2006-09-19 17:31:02 | Re: vista |