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

From Amit Langote
Subject Re: simplifying foreign key/RI checks
Date
Msg-id CA+HiwqEXXzqWa=RE90Ce2=R9B0vggFrvGZYrupVT3GeY-XXR-g@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
List pgsql-hackers
Thanks for the review.

On Tue, Dec 21, 2021 at 5:54 PM Zhihong Yu <zyu@yugabyte.com> wrote:
> Hi,
>
> +   int         lockflags = 0;
> +   TM_Result   test;
> +
> +   lockflags = TUPLE_LOCK_FLAG_LOCK_UPDATE_IN_PROGRESS;
>
> The above assignment can be meged with the line where variable lockflags is declared.

Sure.

> +   GetUserIdAndSecContext(&save_userid, &save_sec_context);
>
> save_userid -> saved_userid
> save_sec_context -> saved_sec_context

I agree that's better though I guess I had kept the names as they were
in other functions.

Fixed nevertheless.

> +        * the transaction-snapshot mode.  If we didn't push one already, do
>
> didn't push -> haven't pushed

Done.

> For ri_PerformCheck():
>
> +   bool        source_is_pk = true;
>
> It seems the value of source_is_pk doesn't change - the value true can be plugged into ri_ExtractValues() calls
directly.

OK, done.

v13 is attached.

-- 
Amit Langote
EDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: In-placre persistance change of a relation
Next
From: Julien Rouhaud
Date:
Subject: Re: SQL/JSON: JSON_TABLE