Re: [HACKERS] GSoC 2017: Foreign Key Arrays - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Date
Msg-id CALNJ-vRMKNQH6v82dKf-rcH9Eyk8e_5Eq85UgJ6aXofbCZJUjA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Mark Rofail <markm.rofail@gmail.com>)
Responses Re: [HACKERS] GSoC 2017: Foreign Key Arrays
List pgsql-hackers
Hi,
In v11-0004-fk_arrays_elems_edits.patch :

+                           riinfo->fk_reftypes[i] == FKCONSTR_REF_EACH_ELEMENT ? OID_ARRAY_ELEMCONTAINED_OP : riinfo->pf_eq_oprs[i], // XXX

Is XXX placeholder for some comment you will fill in later ?

Cheers

On Sat, Mar 20, 2021 at 11:42 AM Mark Rofail <markm.rofail@gmail.com> wrote:
Hey Andreas and Joel!

Thank you so much for your hard work!

1. I have removed the dependency on count(DISTINCT ...) by using an
anti-join instead. The code is much clearer now IMHO.
It is much cleaner! I

2. That instead of selecting operators at execution time we save which
operators to use in pg_constraint. 
This is a clever approach. If you have any updates on this please let me know.

I am still reviewing your changes. I have split your changes from my work to be able to isolate the changes and review them carefully. And to help others review the changes.

Changelist:
- v11 (compatible with current master 2021, 03, 20, commit e835e89a0fd267871e7fbddc39ad00ee3d0cb55c)
    * rebase
    * split andreas and joel's work


On Tue, Mar 16, 2021 at 1:27 AM Andreas Karlsson <andreas@proxel.se> wrote:
On 3/15/21 4:29 PM, Mark Rofail wrote:
> Actually, your fix led me in the right way, the issue was how windows
> handle pointers.

Hi,

I have started working on a partially new strategy for the second patch.
The ideas are:

1. I have removed the dependency on count(DISTINCT ...) by using an
anti-join instead (this was implemented by Joel Jacobson with cleanup
and finishing touches by me). The code is much clearer now IMHO.

2. That instead of selecting operators at execution time we save which
operators to use in pg_constraint. This is heavily a work in progress in
my attached patches. I am not 100% convinced this is the right way to go
but I plan to work some on this this weekend to see how ti will work out.

Another thing I will look into is you gin patch. While you fixed it for
simple scalar types which fit into the Datum type I wonder if we do not
also need to copy types which are too large to fit into a Datum but I
have not investigated yet which memory context the datum passed to
ginqueryarrayextract() is allocated in.

Andreas

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Custom compression methods (mac+lz4.h)
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Custom compression methods (mac+lz4.h)