Re: [HACKERS] GSoC 2017: Foreign Key Arrays

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 <zyu(at)yugabyte(dot)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(dot)rofail(at)gmail(dot)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(at)proxel(dot)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
>>>
>>>