From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Mark Rofail <markm(dot)rofail(at)gmail(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-11 22:53:59 |
Message-ID: | 20170711225359.sayofgbkb2wzimys@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Rofail wrote:
> - now the RI checks utilise the @>(anyarray, anyelement)
> - however there's a small problem:
> operator does not exist: integer[] @> smallint
> I assume that external casting would be required here. But how can I
> downcast smallint to integer or interger to numeric automatically ?
We have one opclass for each type combination -- int4 to int2, int4 to
int4, int4 to int8, etc. You just need to add the new strategy to all
the opclasses.
BTW now that we've gone through this a little further, it's starting to
look like a mistake to me to use the same @> operator for (anyarray,
anyelement) than we use for (anyarray, anyarray). I have the feeling
we'd do better by having some other operator for this purpose -- dunno,
maybe @>> or @>. ... whatever you think is reasonable and not already
in use. Unless there is some other reason to pick @> for this purpose.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Amira Shawky | 2017-07-11 23:30:08 | Finding the min bounding box of an Index leaf page |
Previous Message | Mark Rofail | 2017-07-11 22:27:40 | Re: GSoC 2017: Foreign Key Arrays |