From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Mark Rofail" <markm(dot)rofail(at)gmail(dot)com>, "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Alexander Korotkov" <aekorotkov(at)gmail(dot)com>, "Andreas Karlsson" <andreas(at)proxel(dot)se>, "David Steele" <david(at)pgmasters(dot)net>, "Erik Rijkers" <er(at)xs4all(dot)nl>, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>, "Michael Paquier" <michael(at)paquier(dot)xyz>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Stephen Frost" <sfrost(at)snowman(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Zhihong Yu" <zyu(at)yugabyte(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
Date: | 2021-02-12 20:59:49 |
Message-ID: | bb94c987-9a3e-4547-8fee-71cc062e9263@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Mark,
On Fri, Feb 12, 2021, at 20:56, Mark Rofail wrote:
>Indeed you are right, to support the correct behaviour we have to use @>>(anycompatiblearray, anycompatiblenonarry) and >this throws a sanity error in opr_santiy since the left operand doesn't equal the gin opclass which is anyarray. I am thinking >to solve this we need to add a new opclass under gin "compatible_array_ops" beside the already existing "array_ops", >what do you think?
I'm afraid I have no idea. I don't really understand how these "anycompatible"-types work, I only knew of "anyarray" and "anyelement" until recently. I will study these in detail to get a better understanding. But perhaps you could just explain a quick question first:
Why couldn't/shouldn't @>> and <<@ be operating on anyarray and anyelement?
This would seem more natural to me since the Array Operators versions of @> and <@ operate on anyarray.
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2021-02-12 21:00:21 | Re: snowball update |
Previous Message | David Zhang | 2021-02-12 20:03:56 | Re: [BUG] Autovacuum not dynamically decreasing cost_limit and cost_delay |