ScalarArrayOpExpr and multi-dimensional arrays - Mailing list pgsql-hackers

From Amit Langote
Subject ScalarArrayOpExpr and multi-dimensional arrays
Date
Msg-id faad29ca-61e3-5d8d-7e0f-3552103dea5f@lab.ntt.co.jp
Whole thread Raw
Responses Re: ScalarArrayOpExpr and multi-dimensional arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.