Tom Lane <t...@sss.pgh.pa.us> wrote:
> regression=# select array[1,2] || 3::myi;
> ERROR: operator does not exist: integer[] || myi
>
> In this case, one might expect myi to be automatically downcast to
< int so that it could be matched up with the int array, but that's
> not happening.
I guess it should allow that, although for my uses of domains it's
hard to see a reasonable use case for it, so that part doesn't
bother me too much.
> regression=# create domain myia as int[];
> CREATE DOMAIN
> regression=# select array[1,2]::myia || 3;
> ?column?
> ----------
> {1,2,3}
> (1 row)
>
> So we will downcast myia to int[], or at least one might assume
> that's what's happening. But actually it's worse than that: the
> result of this operation is thought to be myia not int[], because
> myia itself is taken as matching ANYARRAY, and the operator result
> is the same ANYARRAY type.
That is actually what I would want and expect. Let's say I have an
array of attorney bar numbers, and I add one more as a literal.
While an argument could be made that the integer should be cast to
a bar number before being added to the array, we don't require that
for an assignment to a simple variable in the domain, so it would be
surprising to require a cast here, and even more surprising for the
concatenation to result in an array of primitive integers rather
than a array of attorney bar numbers.
> regression=# create domain myia2 as int[]
> check(array_length(value,1) = 2);
> CREATE DOMAIN
> regression=# select array[1,2]::myia2 || 3;
> ?column?
> ----------
> {1,2,3}
> (1 row)
> So we have a value that's claimed to belong to the domain, but it
> doesn't meet the domain's constraints.
Yeah, that's obviously wrong.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
