Tom Lane wrote:
> 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.
Hmm, yeah that's more accurate.
> I'm not sure about
> the typmod handling (need more caffeine to work that out).
Seems straightforward to me. The ArrayExpr should have the typmod of the
base type, as returned by getBaseTypeAndTypmod, and domains don't have
typmods.
> Do you want to have another go at it, or shall I?
I'll give it a shot.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com