From: | Mark Rofail <markm(dot)rofail(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: GSoC 2017: Foreign Key Arrays |
Date: | 2017-07-19 11:56:19 |
Message-ID: | CAJvoCusMda4wDMge5VF9s_yPQsJF0aSaSuHF=Uvhc2szMf3BxQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 18, 2017 at 11:14 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
>
> Why did we add an operator and not a support
> procedure?
I thought the support procedures were constant within an opclass. They
implement the mandotary function required of an opclass. I don't see why we
would need to implement new ones since they already deal with the lefthand
operand which is the refrencing coloumn and is always an array so anyarray
would suffice.
Also the support procedure don't interact with the left and right operands
simultanously. And we want to target the combinations of int4[] @>> int8,
int4[] @>> int4, int4[] @>> int2, int4[] @>> numeric.
So I think implementing operators is the way to go.
Best Regards,
Mark Rofail.
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Rofail | 2017-07-19 12:08:22 | Re: GSoC 2017: Foreign Key Arrays |
Previous Message | david.turon | 2017-07-19 11:00:54 | Re: JSONB - JSONB operator feature request |