Re: Open 7.4 items
От | Stephan Szabo |
---|---|
Тема | Re: Open 7.4 items |
Дата | |
Msg-id | 20031005152122.M80814@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Open 7.4 items (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Open 7.4 items
|
Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: