ScalarArrayOpExpr and multi-dimensional arrays
От | Amit Langote |
---|---|
Тема | ScalarArrayOpExpr and multi-dimensional arrays |
Дата | |
Msg-id | faad29ca-61e3-5d8d-7e0f-3552103dea5f@lab.ntt.co.jp обсуждение исходный текст |
Ответы |
Re: ScalarArrayOpExpr and multi-dimensional arrays
|
Список | pgsql-hackers |
Hi. I wonder if ScalarArrayOpExpr is not really meant for multi-dimensional arrays appearing on the right hand side? Because: # select array[1] = any (array[array[1], array[2]]); ERROR: operator does not exist: integer[] = integer LINE 1: select array[1] = any (array[array[1], array[2]]); ^ HINT: No operator matches the given name and argument types. You might need to add explicit type casts. I noticed this when looking at the constraint of a list partitioned table on a int[] column. create table p (a int[]) partition by list (a); create table p1 partition of p for values in ('{1}'); \d+ p1 ... Partition of: p FOR VALUES IN ('{1}') Partition constraint: ((a IS NOT NULL) AND ((a)::anyarray OPERATOR(pg_catalog.=) ANY (ARRAY['{1}'::integer[]]))) I got the same error as above when I try to put that ANY expression in a query: select (a)::anyarray OPERATOR(pg_catalog.=) ANY (ARRAY['{1}'::integer[]]) from p; ERROR: operator does not exist: integer[] pg_catalog.= integer I guess we shouldn't be generating such a constraint expression if backend is not going to accept the same. Or should ScalarArrayOpExpr be made to sanely process multi-dimensional arrays appearing on the right hand side? Thanks, Amit
В списке pgsql-hackers по дате отправления: