On Sun, 5 Oct 2003, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > I wasn't sure what to do about some of the spi error conditions. For many
> > of them I'm just returning false now so that it will try the other
> > mechanism in case that might work. I'm not really sure if that's worth it,
> > or if I should just elog(ERROR) and give up.
>
> I think you may as well keep it the same as the other RI routines and
> just elog() on SPI error. If SPI is broken, the trigger procedure is
> gonna fail too.
Okay.
> I changed that, consolidated the error-reporting code, and fixed a couple
> other little issues, notably:
>
> * The generated query applied ONLY to the FK table but not the PK table.
> I assume this was just an oversight.
Yep, dumb oversight.
> * The query is now run using SPI_execp_current and selecting "current"
> snapshot. Without this, we could fail in a serializable transaction
> if someone else has already committed changes to either relation.
You'd think I'd have remembered this could happen given the recent
discussions. I was wondering if we could get the serialization failure
with for update, but that's disallowed on the nullable side of the outer
join. It's probably okay to give the no such key error in the delete case
(at some point it'd be nice to make it give serialization failure, but
that might take alot more work than is warrented at this time for 7.4)