Dmitry Yemanov wrote:

>
> To answer this for sure, we need to implement ALTER for all objects depended
> on (including views, computed columns, etc). This is what people miss a lot.

Sean, would that address your concerns?

>
> A question - should ALTER PROCEDURE succeed if we change a VARCHAR parameter
> to be INT? What about DOUBLE -> NUMERIC(18, 2)?

I guess I'd allow any change and live with the problems a really stupid
change introduced.

> The same for table columns,
> as procedure's BLR references them without format, AFAIR. This is the most
> desirable reason for metadata invalidation.
>

Formats get brought into statements during blr compilation. The blr
itself is independent of record formats. The philosophy of the blr
language is to define the desired type in message and throw conversion
errors if the stored type cannot be coerced into the requested type. So
a procedure created when a field was a string should continue to work
even if that field was changed to something else. As above, if the
change goes from a less restrictive type to a more restrictive type,
then give conversion errors.

Regards,


Ann