Adjust psql \d query to avoid use of @> operator.

It seems that the parray_gin extension has seen fit to introduce a
"text[] @> text[]" operator, which conflicts with the core
"anyarray @> anyarray" operator, causing ambiguous-operator failures
if the input arguments are coercible to text[] without being exactly
that type.  This strikes me as a bad idea, but it's out there and
people use it.  As of v10, that breaks psql's query that tries to
test "pg_statistic_ext.stxkind @> '{d}'", since stxkind is char[].
The best workaround seems to be to avoid use of that operator.
We can use a scalar-vs-array test "'d' = any(stxkind)" instead;
that's arguably more readable anyway.

Per report from Justin Pryzby.  Backpatch to v10 where this
query was added.

Discussion: https://postgr.es/m/20171022181525.GA21884@telsasoft.com

diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 06885715a61cd23a646aaa33a0c149a5e154b239..638275ca2f97c3d13dcdbdfce1ef8f75c677465d 100644 (file)
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -2423,8 +2423,8 @@ describeOneTableDetails(const char *schemaname,
                              "   FROM pg_catalog.unnest(stxkeys) s(attnum)\n"
                              "   JOIN pg_catalog.pg_attribute a ON (stxrelid = a.attrelid AND\n"
                              "        a.attnum = s.attnum AND NOT attisdropped)) AS columns,\n"
-                             "  (stxkind @> '{d}') AS ndist_enabled,\n"
-                             "  (stxkind @> '{f}') AS deps_enabled\n"
+                             "  'd' = any(stxkind) AS ndist_enabled,\n"
+                             "  'f' = any(stxkind) AS deps_enabled\n"
                              "FROM pg_catalog.pg_statistic_ext stat "
                              "WHERE stxrelid = '%s'\n"
                              "ORDER BY 1;",