Re: [HACKERS] GSoC 2017: Foreign Key Arrays

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
>>
>>