aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/json.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-10-22 16:45:16 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-10-22 16:45:16 -0400
commit471d55859c11b40059aef7dd82f82b3a0dc338b1 (patch)
treec51b40febca6dbf4dffe036aa6f8adb51cc68360 /src/backend/utils/adt/json.c
parent7c981590c2e8149a88f6b53829770e2277336879 (diff)
downloadpostgresql-471d55859c11b40059aef7dd82f82b3a0dc338b1.tar.gz
postgresql-471d55859c11b40059aef7dd82f82b3a0dc338b1.zip
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
Diffstat (limited to 'src/backend/utils/adt/json.c')
0 files changed, 0 insertions, 0 deletions