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

From Mark Rofail
Subject Re: Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Date
Msg-id CAJvoCuuM6p=f80aUs0XwFiE7Lu5f39xC+kX9Ru6MAaXU9tXqQw@mail.gmail.com
Whole thread Raw
In response to Re: Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (David Steele <david@pgmasters.net>)
Responses Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On 3/7/18 5:43 AM, Alvaro Herrera wrote:
I searched for the new GIN operator so that I
could brush it up for commit ahead of the rest -- only to find out that
it was eviscerated from the patch between v5 and v5.1.
The latest version of the patch which contained the new GIN operator is version  `Array-ELEMENT-foreign-key-v6.patch` which works fine and passed all the regression tests at the time (2018-01-21). We abandoned the GIN operator since it couldn't follow the same logic as the rest of GIN operators use since it operates on a Datum not an array. Not because of any error.

just as Andreas said

On Wed, Jan 31, 2018 at 1:52 AM, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
 The issue I see is that 
ginqueryarrayextract() needs to make a copy of the search key but to do 
so it needs to know the type of anyelement (to know if it needs to 
detoast, etc). But there is as far as I can tell no way to check the 
type of anyelement in this context.
 
If there is any way to  obtain a copy of the datum I would be more than happy to integrate the GIN operator to the patch.

Best.
Mark Rofail

pgsql-hackers by date:

Previous
From: Damir Simunic
Date:
Subject: Re: Proposal: http2 wire format
Next
From: Tomas Vondra
Date:
Subject: Re: Parallel Aggregates for string_agg and array_agg