Hi Zhihing, I think @Andreas ment to mark it as a todo to cleanup later. On Sun, 21 Mar 2021 at 4:49 AM Zhihong Yu <z...@yugabyte.com> wrote:
> 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 >>> >>>
