From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
cc: Mark Rofail <markm.rofail@gmail.com>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        Robert Haas <robertmhaas@gmail.com>,
        David Steele <david@pgmasters.net>,
 Stephen Frost <sfrost@snowman.net>,
        pgsql-hackers-owner@postgresql.org, Erik Rijkers <er@xs4all.nl>
Subject: Re: GSoC 2017: Foreign Key Arrays
In-reply-to: 
 <CAPpHfdtpJZheekg6LhQb7fPxsUF4p9h3qRiBgqATZbhdFPD=ZQ@mail.gmail.com>
References: <17185.1501392410@sss.pgh.pa.us>
 <20170731151805.nonu6qwv54ca4qvv@alvherre.pgsql>
 <CAJvoCutJVR6Yx8C7c1DUzrqx2ZuXmijMMNFv-zC3+5wpd1VQAQ@mail.gmail.com>
 <CAJvoCuuzY7a=Eqv0nCQjYEz3TE2gzd4j+rDTBn2S5yBjcvZ=KQ@mail.gmail.com>
 <CAJvoCutWOXV1fNu0dZOxerqXmrna+7OgFPrnXEshURuFpPZG6g@mail.gmail.com>
 <CAPpHfdsFyMtmh5m2mA=kRkK_uD8hgBp8mNo2U7jZBmFXQP7DBw@mail.gmail.com>
 <CAJvoCus0Wck+JT4rnt0vMZY+Bi4ZPSA=T=t7QBj_T-YvAKGWpQ@mail.gmail.com>
 <CAPpHfdsd9cvKzcdHgFaPLtF0MiopyGHCfUb4wVkVrPgg4vNkZA@mail.gmail.com>
 <CAJvoCutZWfFjT7YDrvM-XxERBhq2aBoRxR9dXtCAWHo8W3Uzng@mail.gmail.com>
 <CAPpHfdtpJZheekg6LhQb7fPxsUF4p9h3qRiBgqATZbhdFPD=ZQ@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <aekorotkov@gmail.com>
	message dated "Mon, 14 Aug 2017 23:35:22 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10716.1502743565.1@sss.pgh.pa.us>
Date: Mon, 14 Aug 2017 16:46:05 -0400
Message-ID: <10717.1502743565@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Mon, Aug 14, 2017 at 2:09 PM, Mark Rofail <markm.rofail@gmail.com> wrote:
>> I think we should cast the operands in the RI queries fired as follows
>> 1. we get the array type from the right operand
>> 2. compare the two array type and see which type is more "general" (as to
>> which should be cast to which, int2 should be cast to int4, since casting
>> int4 to int2 could lead to data loss). This can be done by seeing which Oid
>> is larger numerically since, coincidentally, they are declared in this way
>> in pg_type.h.

> I'm not sure numerical comparison of Oids is a good idea.

I absolutely, positively guarantee that a patch written that way will be
rejected.

> Should we instead use logic similar to select_common_type() and underlying
> functions?

Right.  What we typically do in cases like this is check to see if there
is an implicit coercion available in one direction but not the other.
I don't know if you can use select_common_type() directly, but it would
be worth looking at.

Also, given that the context here is RI constraints, what you're really
worried about is whether the referenced column's uniqueness constraint
is associated with compatible operators, so looking into its operator
class for relevant operators might be the right way to think about it.
I wrote something just very recently that touches on that ... ah,
here it is:
https://www.postgresql.org/message-id/13220.1502376894@sss.pgh.pa.us

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers