From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Check constraint on domain over an array not executed for array literals |
Date: | 2009-11-13 19:50:11 |
Message-ID: | 4AFDB873.8030404@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> 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.
Ok, committed another patch doing exactly that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-11-13 19:52:25 | CommitFest 2009-11: Almost done with initial assignments |
Previous Message | Florian G. Pflug | 2009-11-13 19:49:26 | Re: Inspection of row types in pl/pgsql and pl/sql |