Re: simplifying foreign key/RI checks - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: simplifying foreign key/RI checks
Date
Msg-id CADkLM=fUSg2529pAgGg_y+sG4Jx-1N-RnuMsw7RXH82NPh+oiQ@mail.gmail.com
Whole thread Raw
In response to Re: simplifying foreign key/RI checks  (Zhihong Yu <zyu@yugabyte.com>)
Responses Re: simplifying foreign key/RI checks  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers


On Sat, Jan 23, 2021 at 12:52 PM Zhihong Yu <zyu@yugabyte.com> wrote:
Hi,

+       for (i = 0; i < riinfo->nkeys; i++)
+       {
+           Oid     eq_opr = eq_oprs[i];
+           Oid     typeid = RIAttType(fk_rel, riinfo->fk_attnums[i]);
+           RI_CompareHashEntry *entry = ri_HashCompareOp(eq_opr, typeid);
+
+           if (pk_nulls[i] != 'n' && OidIsValid(entry->cast_func_finfo.fn_oid))

It seems the pk_nulls[i] != 'n' check can be lifted ahead of the assignment to the three local variables. That way, ri_HashCompareOp wouldn't be called when pk_nulls[i] == 'n'.

+           case TM_Updated:
+               if (IsolationUsesXactSnapshot())
...
+           case TM_Deleted:
+               if (IsolationUsesXactSnapshot())

It seems the handling for TM_Updated and TM_Deleted is the same. The cases for these two values can be put next to each other (saving one block of code).

Cheers

I'll pause on reviewing v4 until you've addressed the suggestions above.

 

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Is Recovery actually paused?
Next
From: Dilip Kumar
Date:
Subject: Re: Is Recovery actually paused?