From: | Mark Rofail <markm(dot)rofail(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(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-19 12:08:22 |
Message-ID: | CAJvoCusUmk7iBNf7ak_FdT+b=tot3smRNH9DOjDMUEzNFXgrfg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
*To summarise,* the options we have to solve the limitation of the
@>(anyarray , anyelement) where it produces the following error: operator
does not exist: integer[] @> smallint
*Option 1: *Multiple Operators
Have separate operators for every combination of datatypes instead of a
single polymorphic definition (i.e int4[] @>> int8, int4[] @>> int4, int4[]
@>> int2, int4[] @>> numeric.)
Drawback: High maintenance.
*Option 2: *Explicit casting
Where we compare the datatype of the 2 operands and cast with the
appropriate datatype
Drawback: figuring out the appropriate cast may require considerable
computation
*Option 3:* Unsafe Polymorphic datatypes
This a little out there. But since @>(anyarray, anyelement) have to resolve
to the same datatype. How about defining new datatypes without this
constraint? Where we handle the datatypes ourselves? It would ve something
like @>(unsafeAnyarray, unsafeAnyelement).
Drawback: a lot of defensive programming has to be implemented to guard
against any exception.
*Another thing*
Until this is settled, another thing I have to go through is performance
testing. To provide evidence that all we did actually enhances the
performance of the RI checks. How can I go about this?
Best Regards,
Mark Rofail
From | Date | Subject | |
---|---|---|---|
Next Message | Neha Sharma | 2017-07-19 12:26:55 | [TRAP: FailedAssertion] causing server to crash |
Previous Message | Mark Rofail | 2017-07-19 11:56:19 | Re: GSoC 2017: Foreign Key Arrays |