Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Florian G. Pflug wrote:
>> It seems that check constraints on domains are *not* executed for
>> literals of the domain-over-array-type - in other words, for expressions
>> like:
>> array[...]::<my-domain-over-array-type>.
> There's a special case in transformExpr function to handle the
> "ARRAY[...]::arraytype" construct, which skips the usual type-casting
> and just constructs an ArrayExpr with the right target type. However,
> it's not taking into account that the target type can be a domain.
> Attached patch fixes that. Anyone see a problem with it?
Hm. I concur that this special-case code is failing to consider the
possibility that the target type is domain-over-array-type rather than
just array-type. I think though that this patch is a bit of a kluge,
because it delivers a mislabeled expression tree. The result of the
transformArrayExpr() is not really of type myintarray. What it is is
a plain int[] value; we shouldn't label it as being already myintarray,
because it hasn't passed the domain checks. At the moment there is
probably not any visible effect of that, but in the future it could
lead to misoptimization, so I think it's important to get it right.
My inclination is to apply getBaseTypeAndTypmod to the targetType and
pass that as the array type to transformArrayExpr, then instead of
considering the job done, fall through to transformTypeCast, which will
either do nothing or attach a domain coercion node. I'm not sure about
the typmod handling (need more caffeine to work that out).
Do you want to have another go at it, or shall I?
regards, tom lane
