Re: Re: [HACKERS] GSoC 2017: Foreign Key Arrays
| От | Mark Rofail |
|---|---|
| Тема | Re: Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
| Дата | |
| Msg-id | CAJvoCuuM6p=f80aUs0XwFiE7Lu5f39xC+kX9Ru6MAaXU9tXqQw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Re: [HACKERS] GSoC 2017: Foreign Key Arrays (David Steele <david@pgmasters.net>) |
| Ответы |
Re: [HACKERS] GSoC 2017: Foreign Key Arrays
|
| Список | 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
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.
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.
Best.
Mark Rofail
В списке pgsql-hackers по дате отправления: