From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | ScalarArrayOpExpr and multi-dimensional arrays |
Date: | 2017-12-08 09:12:45 |
Message-ID: | faad29ca-61e3-5d8d-7e0f-3552103dea5f@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bernd Helmle | 2017-12-08 09:13:00 | Re: PostgreSQL crashes with SIGSEGV |
Previous Message | Masahiko Sawada | 2017-12-08 08:38:08 | Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted. |