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.rof...@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 <andr...@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 >> >>
