On Mon, Aug 14, 2017 at 2:09 PM, Mark Rofail <markm.rof...@gmail.com> wrote:

> On Tue, Aug 8, 2017 at 3:24 PM, Alexander Korotkov <aekorot...@gmail.com>
> wrote:
>> On Tue, Aug 8, 2017 at 4:12 PM, Mark Rofail <markm.rof...@gmail.com>
>> wrote:
>>> On Tue, Aug 8, 2017 at 2:25 PM, Alexander Korotkov <aekorot...@gmail.com
>>> > wrote:
>> GROUP BY would also use default btree/hash opclass for element type.  It
>>>> doesn't differ from DISTINCT from that point.
>>> Then there's no going around this limitation,
>> That seems like this.
> Since for now, the limitation
>> ✗ presupposes that count(distinct y) has exactly the same notion of
>> equality that the PK unique index has. In reality, count(distinct) will
>> fall back to the default btree opclass for the array element type.
> is unavoidable.
> I started to look at the next one on the list.
>> ✗ coercion is unsopported. i.e. a numeric can't refrence int8
> The limitation in short.
> #= CREATE TABLE PKTABLEFORARRAY ( ptest1 int4 PRIMARY KEY, ptest2 text );
> OF ftest1) REFERENCES PKTABLEFORARRAY, ftest2 int );
> should be accepted but this produces the following error
> operator does not exist: integer[] @> smallint
> The algorithm I propose:
> I don't think it's easy to modify the @>> operator as we discussed here.
> <https://www.postgresql.org/message-id/CAJvoCusUmk7iBNf7ak_FdT%2Bb%3Dtot3smRNH9DOjDMUEzNFXgrfg%40mail.gmail.com>
> 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.  AFAIK, any
regularity of Oids assignment is coincidence...  Also, consider
user-defined data types: their oids depend on order of their creation.
Should we instead use logic similar to select_common_type() and underlying

Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Reply via email to