GIN ne supporte pas les parcours d'index complets. La raison est que extractValue est autorisée à retourner zéro clés, ce qui pourrait par exemple arriver avec une chaîne vide ou un tableau vide. Dans ce cas la valeur indexée ne sera pas présente dans l'index. Il est donc impossible à GIN de garantir que le parcours d'un index trouvera tous les enregistrements de la table.

En raison de cette limitation, quand extractQuery retourne nkeys = 0 pour indiquer que toutes les valeurs correspondent à la requête, GIN émettra une erreur. (Si il y a plusieurs opérateurs indexables liés par des ET logiques, cela n'arrivera que si ils retournent tous nkeys = 0.)

Il est possible pour un opérateur de contourner cette restriction sur les scans d'index. Pour cela, extractValue doit conserver au moins une (éventuellement factice) clé pour toutes les valeurs indexées, et extractQuery doit convertir la recherche sans limitations en une requête de correspondance partielle qui parcourera l'ensemble de l'index. C'est inefficace, mais peut être nécessaire pour éviter des cas particuliers d'échec avec certains opértateurs comme LIKE ou l'inclusion de sous-ensemble.

GIN suppose que les opérateurs indexables sont stricts. Cela signifie que extractValue ne sera pas appelé du tout sur une valeur NULL (et que donc la valeur ne sera pas indexée), et que extractQuery ne sera pas appelée sur une valeur de comparaison NULL non plus (à la place, la requête est supposée ne pouvant pas correspondre).

Une limitation qui peut être plus sérieuse est que GIN ne peut pas pas gérer des clés NULL  -- par exemple, un tableau contenant une valeur NULL ne peut pas être gérée, excepté en ignorant la valeur NULL.