Re: GSoC 2017: Foreign Key Arrays

As pointed out by the CI, created by Thomas Munro, the btree_gin regression
tests fail when running "make check-world"
https://travis-ci.org/postgresql-cfbot/postgresql/builds/274732512

The full backtrace can be found here: https://pastebin.com/5q3SG8kV.

The error originates from src/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 ONLY fktable x WHERE ARRAY[$1] <@ fkcol FOR
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.

Best Regards,
Mark Rofail