Dmitry Yemanov wrote:

> Adriano,
>
>
>>> What if the change to the domain means that the SP is not recompilable?
>>>
>>
>> AFAIK the only thing with may cause that is arrays.
>> We don't allow arrays in PSQL and arrays could be used in domains.
>> The rejection for domain arrays should be done at runtime.
>>
>
> CREATE DOMAIN D INT;
> DECLARE V1 D;
> DECLARE V2 D;
> DECLARE V3 D;
> V3 = V1 + V2;
>
> If someone would change a domain to become VARCHAR, this PSQL code won't
> parse (at least in DSQL) in Dialect 3. Perhaps a BLR parse will miss that
> mismatch, but it would also mean that a *compatible* data change
> (INT->VARCHAR) will cause runtime errors during execution. This is yet
> another issue to be added to the BLR invalidation mechanism.
>
> Also, I think there may be other cases (besides arrays) when BLR won't parse
> after a type change. For example, a format (e.g. for some select statement
> inside PSQL code) could become more than 32K in length after increasing
> [VAR]CHAR size.

Ok they don't parse because we know they will not work at runtime.
Anyway we already have that type of thing with triggers, i.e. runtime
failure.

We can change a field data type with existing trigger using it with OLD
and NEW.


Adriano