Alexander Korotkov <aekorot...@gmail.com> writes: > On Mon, Aug 14, 2017 at 2:09 PM, Mark Rofail <markm.rof...@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.1502376...@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
