| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | Mark Rofail <markm(dot)rofail(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-18 21:14:52 |
| Message-ID: | 20170718211452.xoyjp24wkoju3hfr@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alexander Korotkov wrote:
> The problem is that you need to have not only opclass entries for the
> operators, but also operators themselves. I.e. separate operators for
> int4[] @>> int8, int4[] @>> int4, int4[] @>> int2, int4[] @>> numeric. You
> tried to add multiple pg_amop rows for single operator and consequently get
> unique index violation.
>
> Alvaro, do you think we need to define all these operators? I'm not sure.
> If even we need it, I think we shouldn't do this during this GSoC. What
> particular shortcomings do you see in explicit cast in RI triggers queries?
I'm probably confused. Why did we add an operator and not a support
procedure? I think we should have added rows in pg_amproc, not
pg_amproc. I'm very tired right now so I may be speaking nonsense.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Cave-Ayland | 2017-07-18 21:35:26 | Re: More flexible LDAP auth search filters? |
| Previous Message | Alvaro Herrera | 2017-07-18 21:13:31 | Re: GSoC 2017: Foreign Key Arrays |