Re: augmenting MultiXacts to improve foreign keys
От | Tom Lane |
---|---|
Тема | Re: augmenting MultiXacts to improve foreign keys |
Дата | |
Msg-id | 12383.1312922415@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: augmenting MultiXacts to improve foreign keys (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: augmenting MultiXacts to improve foreign keys
Re: augmenting MultiXacts to improve foreign keys Re: augmenting MultiXacts to improve foreign keys |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011: >> Right now, FKs aren't really very special, they are mostly just >> syntactic sugar (right?). This proposal would make FKs special internal >> mechanisms, and I don't see the benefit in doing so. > Well, you can get the same behavior by adding the constraint triggers > manually. But those triggers are written in C, so you could equally > claim that they are "special internal" already. The SPI interface has > some special entry points to allow them to work correctly (for example > passing a snapshot for the checks to run with). Yeah, the crosscheck-snapshot logic already puts the lie to any idea that the RI triggers are equivalent to anything available at the SQL level. ISTM you could pass down the "please do this with FOR KEY UPDATE not just FOR SHARE" flag similarly to the way the crosscheck snapshot is passed down, or maybe even just do it if you see a crosscheck snapshot is present in the executor state (though that's a bit ugly). Like Florian, I'm considerably more concerned about the aspect of deciding which columns are "key columns" and whether they changed. regards, tom lane
В списке pgsql-hackers по дате отправления: