Re: SQL:2011 application time

Поиск
Список
Период
Сортировка
От Paul Jungwirth
Тема Re: SQL:2011 application time
Дата
Msg-id 3b0e067d-9a78-46f7-8027-99c19e7cde44@illuminatedcomputing.com
обсуждение исходный текст
Ответ на Re: SQL:2011 application time  (Sam Gabrielsson <sam@movsom.se>)
Ответы Re: SQL:2011 application time
Список pgsql-hackers
On 11/4/24 13:16, Sam Gabrielsson wrote:
> Foreign key violation errors are incorrectly raised in a few cases for a temporal foreign key with 
> default ON UPDATE NO ACTION. Test is based on the commited v39 patches (used a snapshot version of 
> PG18 devel available from PGDG).

Thank you for the report! I confirmed that this is a problem. In ri_restrict we fail if any fk 
records still match the being-changed pk, but for temporal if you're merely shrinking the pk range, 
fk references could still wind up being valid (if you're only shrinking it a little). So we need to 
do more work.

> In the temporal NO ACTION case something similar to this (though with appropriate locks) could 
> perhaps be tested in ri_restrict (when ri_Check_Pk_Match returns false):
> 
>    SELECT 1
>    FROM (SELECT range_agg(pkperiodatt) AS r
>        FROM <pktable>
>        WHERE pkatt1 = $1 [AND ...]
>        AND pkperiodatt && $n) AS pktable,
>      (SELECT fkperiodatt AS r
>        FROM <fktable>
>        WHERE fkatt1 = $1 [AND ...]
>        AND fkperiodatt && $n) AS fktable
>    WHERE NOT fktable.r <@ pktable.r

This solution looks like it will work to me. Basically: find FKs that still match the PK, but only 
fail if they are no longer covered.

IIRC for RESTRICT it is *correct* to reject the change, so we would want to keep the old SQL there, 
and only update it for NOACTION.

I'll work on a fix and submit another set of patches.

Yours,

-- 
Paul              ~{:-)
pj@illuminatedcomputing.com



В списке pgsql-hackers по дате отправления: