The error originates fromsrc/backend/access/gin/ginscan.c:182, where the following if condition if (strategy == 5 && nQueryValues == 1) returns false postivies .
The if condition is necessary since it decides whether "the queryKey" variable is a single element or the first cell of an array. The logic behind the if condition is as follows: since we defined GinContainsElemStrategy to be strategy number 5. are sure the strategy is GinContainsElemStrategy. The if condition needs to be more precise but can't find a common attribute to check within the ginFillScanKey() function.
If someone can take a look. I can use some help with this.
I also worked in another direction. Since there was a lot of modifications in the code to support taking an element instead of an array and this is the source of many conflicts. I tried going back to the old RI query:
SELECT 1 FROM ONLY fktable x WHERE ARRAY[$1] <@ fkcol FOR SHARE OF x;
instead of
SELECT 1 FROM ONLY fktable x WHERE $1 @>fkcol FOR SHARE OF x;
We were worried about the decrease in performance caused by creating a new array with every check So I put it to the test and here are the results: https://pastebin.com/carj9Bur
note: v5 is with SELECT 1 FROM ONLY fktable x WHERE $1 @>fkcol FOR SHARE OF x;
and v5.1 is with SELECT 1 FROM ONLYfktablex WHERE ARRAY[$1] <@fkcolFOR SHARE OF x;
As expected it led to a decrease in performance, but I think it is forgivable. Now all the contrib regression tests pass.
To summarise, we can fix the old if condition or neglect the decrease in performance encountered when going back to the old RI query.
