On Friday 15 August 2008 14:43, Adriano dos Santos Fernandes wrote:

> Alex Peshkov escreveu:
> > On Thursday 14 August 2008 17:58, Adriano dos Santos Fernandes wrote:
> >> Dmitry Yemanov escreveu:
> >>> Imagine some user selecting two fields (debit and credit) from a
> >>> procedure and someone else alters this procedure and changes the output
> >>> parameters order to the opposite one. The message format is still the
> >>> same, but the user application will start getting completely crazy
> >>> financial information. Should we care about such dumb situations?
> >>
> >> Yes, I think so. We can do it in DSQL verifying SQLDA members (type
> >> information, relation and field name) instead of doing it in engine
> >> format block.
> >
> > Adriano, I suppose you see yourself that in general case this is not
> > possible. Imagine that in the end of procedure someone changed:
> >
> > ret1 = UDF_debet(bla-la-la1);
> > ret2 = UDF_kredit(bla-la-la2);
> >
> > to:
> >
> > ret2 = UDF_debet(bla-la-la1);
> > ret1 = UDF_kredit(bla-la-la2);
> >
> > Type information is OK, no relation and field name at all. It's even
> > possible to redeclare UDFs!
> >
> > I do not think we must take care about such cases - if format of messages
> > is OK, it's absolutely useless to try to care about something else. Or we
> > must always throw an error if some object is changed!
>
> I think your example is not valid. On Dmitry example, it would be caused
> only in "select *" or "insert into table values (...)" (i.e., without
> field lists) and also with procedure input parameters.
>
> The re-prepared statement should have consistent input and output with
> the original one and it's simple to verify it. This is from client POV.
>
> If you're arguing about procedure body, this is not related to
> re-preparation verification.

Well, looks like we misunderstood each other. I see no problems doing all
possible verifications.