Re: [HACKERS] GSoC 2017: Foreign Key Arrays
| От | Mark Rofail |
|---|---|
| Тема | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
| Дата | |
| Msg-id | CAJvoCusUmk7iBNf7ak_FdT+b=tot3smRNH9DOjDMUEzNFXgrfg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] GSoC 2017: Foreign Key Arrays (Mark Rofail <markm.rofail@gmail.com>) |
| Ответы |
Re: [HACKERS] GSoC 2017: Foreign Key Arrays
|
| Список | 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
Option 2: Explicit casting
Another thing
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
Mark Rofail
В списке pgsql-hackers по дате отправления: