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

From Corey Huinker
Subject Re: simplifying foreign key/RI checks
Date
Msg-id CADkLM=cModCxno2pExyWzhfGkH6_+aton864SUh89BXxjJ==vw@mail.gmail.com
Whole thread Raw
In response to Re: simplifying foreign key/RI checks  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: simplifying foreign key/RI checks  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers


I decided not to deviate from pk_ terminology so that the new code
doesn't look too different from the other code in the file.  Although,
I guess we can at least call the main function
ri_ReferencedKeyExists() instead of ri_PrimaryKeyExists(), so I've
changed that.

I think that's a nice compromise, it makes the reader aware of the concept.
 

I've attached the updated patch.

Missing "break" added. Check.
Comment updated. Check.
Function renamed. Check.
Attribute mapping matching test (and assertion) added. Check.
Patch applies to an as-of-today master, passes make check and check world.
No additional regression tests required, as no new functionality is introduced.
No docs required, as there is nothing user-facing.

Questions:
1. There's a palloc for mapped_partkey_attnums, which is never freed, is the prevailing memory context short lived enough that we don't care?
2. Same question for the AtrrMap map, should there be a free_attrmap().

pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Next
From: Noah Misch
Date:
Subject: Re: Very misleading documentation for PQreset()