diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2017-10-22 16:45:16 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2017-10-22 16:45:16 -0400 |
commit | 471d55859c11b40059aef7dd82f82b3a0dc338b1 (patch) | |
tree | c51b40febca6dbf4dffe036aa6f8adb51cc68360 /src/backend/utils/adt/json.c | |
parent | 7c981590c2e8149a88f6b53829770e2277336879 (diff) | |
download | postgresql-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