From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Mark Rofail" <markm(dot)rofail(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
Date: | 2021-02-15 15:34:43 |
Message-ID: | 900d3c5b-b1f7-429e-827c-6bc6050ee830@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
I've reviewed Mark's anyarray_anyelement_operators-v2.patch
and the only remaining issue I've identified is the opr_sanity problem.
Mark seems to be in need of some input here from more experienced hackers, see below.
Hopefully someone can guide him in the right direction.
/Joel
On Sat, Feb 13, 2021, at 11:49, Mark Rofail wrote:
>Hey Joel,
>
>test opr_sanity ... FAILED
>
> AND binary_coercible(p2.opcintype, p1.amoplefttype));
> amopfamily | amopstrategy | amopopr
>------------+--------------+---------
>-(0 rows)
>+ 2745 | 5 | 6105
>+(1 row)
>-- Operators that are primary members of opclasses must be immutable (else
>-- it suggests that the index ordering isn't fixed). Operators that are
>This is due using anycompatiblearray for the left operand in @>>.
>To solve this problem we need to use @>>(anyarray,anyelement) or introduce a new opclass for gin indices.
>These are the two approaches that come to mind to solve this. Which one is the right way or is there another solution I am not aware of?
>That’s why I’m asking this on the mailing list, to get the community’s input.
From | Date | Subject | |
---|---|---|---|
Next Message | Seamus Abshere | 2021-02-15 15:42:14 | Re: A reloption for partitioned tables - parallel_workers |
Previous Message | Tomas Vondra | 2021-02-15 14:37:01 | Re: WIP: BRIN multi-range indexes |